Engineering Interfaces II: MVC, Multithreading

From CS160 Spring 2013
Jump to: navigation, search

Contents

Readings

Optional

Reading Responses

Alice Huynh - 3/3/2013 15:34:02

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?

Android does not necessarily follow the MVC paradigm. If I were forced to somewhat consider the Android SDK as an MVC model I could argue that the view is in one XML file and that the controller is expressed in the “main_activity.java” file. I don’t believe that this forced comparison between the Android SDK and the MVC model are very accurate. I would say that the main difference between the Android SDK and the MVC paradigm is the idea of a “model”. The XML file expresses the way the view should look and the “main_activity.java” file allows for event-listeners to know when and how the view has been changed, but there is no instance of the idea of a model to tell the view what it should look like.

In my experience, I’ve worked with Rails and that language conforms perfectly with the MVC paradigm because of the way Rails is structured to look like MVC. The model and the view talk to each other through the controller. In the Android SDK I don’t see that interaction between the model and the view through the controller.

2. The Goetz et al reading describes threading issues for Java Swing, a GUI SDK that many Java desktop applications use. The Android SDK also uses a single GUI thread. 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 is one class called “AsyncTask” that extends from the Object class that allows for threads to “doInBackground” protected Long doInBackground(URL... urls) {

        int count = urls.length;
        long totalSize = 0;
        for (int i = 0; i < count; i++) {
            totalSize += Downloader.downloadFile(urls[i]);
            publishProgress((int) ((i / (float) count) * 100));
            // Escape early if cancel() is called
            if (isCancelled()) break;
        }
        return totalSize;
    }

http://developer.android.com/reference/android/os/AsyncTask.html

This class also allows for cancellation if that is necessary as well. Which is similar to the code snippet in “9.6” in the Goetz et al reading for cancelling a long-running task. The Swing mechanisms and the Android version of productively running long-running tasks are very similar because both create a new “Runnable” to be executed.

Java also contains the “Thread” and “Runnable” classes that are available for all Java programs which can be easily used in our Android applications as well. Threads can have priorities set and can always create a new thread as long as a “Runnable” object is given with the task that the thread should do. Alternatively it’s easy to create a new thread and pretend that, it is the background thread. By calling a thread with the “start()” function instead of the “run()” function, Java will run the thread when it is ready to be executed rather than the user calling it to be run immediately.


Cong Chen - 3/3/2013 23:14:07

1. I believe that the Android SDK does follow the MVC paradigm. For views, you determine the layout and interface via XML files and other resources in the res folder of the project. For the controller, you handle the logic and processing from the user inputs in the .java files in our src folders. Finally, for the Models, you can handle the information storage in the form of java classes or in java files also in the src file (you can define your own data objects, menthols for handling them, etc). Because of this distinct separation, I believe Android SDK does follow the MVC model.

2. For running long-executions, the Android SDK offers similar mechanisms as provided by Swing such as FutureTask, ThreadPoolExecutor, and Executor to aid in creating new executor threads to run long tasks and also be given methods to get the process of the log job, canceling, or calling methods upon completion ( isDone(), cancel(boolean mayInterruptIfRunning), isDone()…etc). For background threads, The Android SDK offers the class AsyncTask, which aids in performing background thread operations and publishing the results to the UI thread. This differs from Swing though in that it is intended ideally to be used for short operations.


Elizabeth Hartoog - 3/3/2013 23:56:37

Android does not follow the MVC paradigm, though it is similar. The XML files describe your interface are similar to a view, though the XML files are not dynamic and can't communicate with the controller as a result. They are however what initially define what the user will see and how objects are laid out in the android view. Activities function as controllers that update the android view (what the user sees). The activity takes information from the user, creates events and uses them to update data and run the application. There is no formal android equivalent for the "model," but can be created as a specialized data structure that interacts with activities. Because the android sdk uses the templating system through xml files, it cannot adhere strictly to the MVC paradigm.


For GUIs it is extremely important that the GUI maintain the illusion of continuity. Any interruption to the GUIs flow can make it appear sluggish, and users do not like slow. Since GUIs are run by a single event thread, it is important to be able to run tasks in the background. Hence, Swing's aptly named background task which was not required to be executed immediately by the GUI event executor while also allowing the developer/user a way of canceling and dealing with slow tasks. Backgroundtask was done by utilizing a background thread and calling an oncomplete function once the computation was complete. For android, it's called asynctask which is not quite the same thing. Async means that the task does not need to be completed when the task is called by the application and will complete whenever it feels like. For the most part asynctask is a mini version of backgroundtask which doesn't involve dealing with the heavy duty threading tools of the android sdk which are similar to swing (executor, futuretask etc). Another way android deals with its single gui thread is through views. When you are done with one view of the application, you must "switch" views by pausing the current view and starting up another.


Zeeshan Javed - 3/4/2013 13:22:13

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?

A person can take a model-view-controller when developing applications on Android, but in actuality the SDK already implements a lot of those details for the developer before they start building their project. For the view you define your user interface in various XML files by resolution/hardware, you define your resources in various XML files by locale, and you extend classes like ListActivity, TabActivity and make use of the XML file. The creation of classes enables the ability to act freely with the model. The Activities section can be seen as the controller. So yes the Android SDK does follow the MVC paradigm if one chooses to read into it that way.

2. The Goetz et al reading describes threading issues for Java Swing, a GUI SDK that many Java desktop applications use. The Android SDK also uses a single GUI thread. 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?

In the Android documents it states that start() Causes this thread to begin execution; the Java Virtual Machine calls the run method of this thread. It is also stated that AsyncTask enables proper and easy use of the UI thread. This class allows to perform background operations and publish results on the UI thread without having to manipulate threads and handlers. Swing mechanisms allowed the look and feel of every component in an application to be changed without making substantial changes to the application code. So they are similar in minor ways but really swing mechanisms , swing components are not implemented by platform-specific code which makes their composition a slightly different.




Soo Hyoung Cheong - 3/4/2013 15:24:21

1. Android SDK does follow the Model-View-Controller paradigm to a certain extent. Models are pretty much the data that would be displayed in the view, which would include resources and user inputted information. The views in Android SDK are like layouts xml files that decides what buttons, TextViews, or Spinner will show in the program. The controller connects the View to Model, which in Android is the Activity class that calls onCreate, onResume, or other methods that takes care of the behind logic of the interaction between the model and view.

2. The Android SDK can use AsyncTask class to create a task that runs process in the background without interrupting the main thread, therefore the main thread is blocked until the background worker thread completes. Also you can spawn off worker threads to run. Also the Android SDK can create foreground, visible, service, background process to handle long-running executions and background threads. These are pretty similar to the Swing mechanisms in terms of how the threading works. Swing can also have short task to be executed that stay as part of the event thread, and the longer tasks are assigned to separate thread. Swing also have class that takes care of the separate tasks to be done, which is FutureTask and it is similar to the AsyncTask in Android. One difference is that Android is thread-safe model, while Swing is not thread-safe.


Jeffery Butler - 3/4/2013 21:09:21

1) The Android SDK follows the Model-View-Controller paradigm. The Model is represented through the activites where the data is stored and modified if necessary. Next, the View is the xml attached to the particular acitvity where the user can insert events which can manipulate the Model. Lastly, the Controller is simply the listeners within the Activity that are attach to the xml layout. When a user interacts with an interface, this consequentially updates the model data by the controller noticing the event.

2) In Android development, one can create background threads by usuing the inner class AsyncTaskImpl where the app creates a background thread and runs a task such as POSTing a server. This is very similiar to the Swing implementation: BackgroundTask. Both of these frameworks can create a background thread to handle a task, return progress, completion notification and cancelable options. On the other side of the coin, both UI threads in Android and Swing can interact with the view and the model during user interaction. In my previous experience, I have only used the UI thread to modify the model and have not allocated the Split Model or Shared Data Models of the Swing data structures. Maybe in Android the background threading is at times done more implicitly than the developer having to define a background thread in cases where optimization is present.


Alvin Yuan - 3/5/2013 1:14:42

Android SDK does not really follow the MVC paradigm. Android seems more organized around different elements of an application communicating with each other, with no object/class distinction between that element's view and model. The different elements can communicate with each other (controller aspects), define how to paint themselves (view aspects), and store their own state (model aspects). For example, take the custom view we created for painting in the second programming assignment. At least for me (though I'm guessing for most students as well), the custom view class encapsulated its own state and redrawing logic. There was no model class that held the state, no controller class that interfaced between view and model; everything was all in one single class. And for my code, that custom view would interact directly with an Activity object that had paint options. In this sense, Android is less about distinguishing between model, view, and controller and more about providing a means of communication between elements that interact. That said, I'm sure high-end applications may write code in such a way that follows the MVC paradigm, but it is not central to Android SDK.

Looking at the developer.android.com site, the Android SDK has access to CursorLoader objects. CursorLoader performs queries asynchronously and then when it completes, connects back to the Activity that it's associated with. This particular class is different from the Swing mechanisms discussed in that it automatically re-runs the query when the data it fetches has been updated. In contrast, the Swing mechanisms discussed involve something triggering a background task to start. The split model design can do something similar but the automatic updating is not built into the design from the get go. Android SDK also has IntentServices that basically act as a background thread for handling asynchronous requests. Heavy operations can be off-loaded to this Service so that the UI thread remains responsive. This sounds similar to the mechanism of using a secondary thread possibly in a threadpool or an Executor. They all sound like they simply off-load long tasks to another thread. Finally, Android SDK has AsyncTask which sounds very similar to the BackgroundTask described in the reading. Both have built-in support for reporting progress, reporting completion, and cancellation.


Zhaochen "JJ" Liu - 3/5/2013 2:55:25

'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?

Yes, it follows the MVC paradigm.

Model: The programmers has to decide on their own whether they want to add some classes to represent some models. They can create as many classes as they want. For example, in the drawing application, I created a “MyPath” class which is a wrapper class of the built-in “android.graphics.Path”.

View: XML files, layouts, images, etc.

Controller: Activities, the user input will trigger some events in the Activates. Then, the controller will do something with the model and update the view.


2. The Goetz et al reading describes threading issues for Java Swing, a GUI SDK that many Java desktop applications use. The Android SDK also uses a single GUI thread. What are the functions, objects and mechanisms in Android that help developers with long-running executions and background threads?

There are generally two ways you can do deal with single GUI thread in Android.

  1. Do it your own. In your main thread, aka GUI thread, you can initiate a new Thread (Runnable) and override the “run()” method.
  2. Use “AsyncTask”. It enables proper and easy use of the UI thread. It can perform background operations and publish results on the UI thread without having to manipulate threads and/or handlers.

The three main types used by an asynchronous task are:

  • Params
  • Progress
  • Result

An asynchronous task generally go through 4 functions:

  • onPreExecute()
  • doInBackground(Params…)
  • onProgressUpdate(Progress…)
  • onPostExecute(Result)


Are they similar or different to the Swing mechanisms?

Similar, because:

  • UI thread in Swing and Android are both single-threaded
  • The idea behind is both an event queue, using the idea of Event Dispatch Thread
  • AsyncTask similar to SwingWorker
  • The way the Android handles events from components is also similar to Swing’s event mechanism.
  • The reason of using single-thread UI model is UI thread will usually only handle drawing and user actions, which will not going be an bottle neck in a most of the applications.


Mukul Murthy - 3/5/2013 12:43:33

Android SDK uses something similar, but not exactly, the Model-View-Controller paradigm. In that paradigm, the View class is the component that displays output and interacts with the user. This corresponds to the Android View class and everything that inherits from it; these are all of the input fields and widgets the user gets to see and use. The Controller object is the intermediary between the View and the Model, which contains internal state and representation of what is supposed to happen. In Android, there are no separate Model and Controller classes. An application's state and "model" is kept in the Activity class, which is also responsible for changing the views and receiving input from users. Thus, an Android Activity class acts as both Controller and Model.

Android uses a single GUI thread for the same reason Swing and other GUI SDKs use a single GUI thread - avoiding deadlock. Because there are both user events that must bubble up and application events that bubble down, it is very difficult to prevent deadlock. If only one thread is available for the GUI, this means that this thread cannot be used for other tasks which don't run extremely quickly, or the GUI would be unresponsive while these tasks were occurring. The alternate - which is also used in Swing - is to have additional background threads to run long functions. However, according to the reading, these "fire and forget" functions are bad; there should be some mechanism of updating the GUI to let the user know what is going on (such as a progress bar). These GUI updates are simple tasks, so they can be done by the GUI thread. When I first connected my Android phone to my computer and put the phone in debug mode to see what threads were running, I was surprised by how many there were; I thought there would be only a couple threads running. Another important requirement the ability to cancel background threads executing long-running processes. This is generally available in Android. Android also seems to use the split model - the program has presentation-domain data and application-domain data. This is similar to how it is in Swing, and is slightly different from the Model-View-Controller paradigm discussed above.


Haotian Wang - 3/5/2013 13:22:50

1) The Android SDK seems to mash together controller and model, while view is somewhat separated. This is in comparison to the MVC of Ruby on Rails, which I have much more experience with than Cocoa. In Rails, the model, view, and controller are all separate files, so that a request (Rails being a web app) gets handled by the controller, which calls the appropriate model to get data and then sends the data to the view to be rendered. In other words, the controller only handles routing, the model only handles actual program logic, and the view only renders what is given to it. In Android the mainActivity.xml is a correlate to the Rails view, in that it's given data by the Java program and renders it. However, there is no clear division between controller and model, since both are the Java logic which can be ordered in any way that the programmer chooses. Certainly, the programmer can put controller methods and model methods into different files, but this is a programmer preference, not any inherent structure of Android. So instead of a MVC architecture, I would say that android has a MV-C architecture. 2) Android has pretty similar methods of multi-threadedness as Swing does. It's a single GUI-threaded system, but forked threads can still access the GUI elements, although the android development guide explicitly states that this should never be done, since it will lead to unexpected non-thread-safe behavior. Android can start new threads to run background tasks in basically the same way as Swing, although the class/method names are obviously different. That is, a thread is started with a runnable which contains the background task, and the runnable must invoke a GUI-thread method to update the GUI, not update the GUI itself. This behavior is wrapped by an android class called AsyncTask, which basically does what's described above, but separates the background job and the UI update nicely by providing a backgroundJob() method and onExecute() method, which does each task respectively.


Winston Hsu - 3/5/2013 15:15:41

1. Yes the Android SDK does mostly follow the Model View Controller paradigm. The Controllers are generally all the listeners that listen for user events. Once they hear an event they can tell the corresponding model/views to do stuff. The Views are all the classes that end in View, like ListView, ImageView, and so on. They represent the actual UI items on the screen. For some more complicated UI elements, there is a Model which connects through the view through Adapters. For example, you can supply ListViews with adapters that contain the information about how to populate the view.

2. Android has the same standard Java threading library, and so works mostly similarly as Swing. Android provides the handler class for making things from other threads run in the UI thread. Android has also added an AsyncTask class that can automatically run code in the background and execute the callback in the UI thread, similar to Swing's BackgroundTask.


Colin Chang - 3/5/2013 20:34:43

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?

Not officially. You might think that the XML layouts map to view and activities map to model/controller. However, the view is coupled with the activity, which violates MVC since "view objects are typically decoupled from model objects in an MVC application." (http://developer.apple.com/library/ios/#documentation/general/conceptual/DevPedia-CocoaCore/MVC.html). I read http://stackoverflow.com/questions/2925054/mvc-pattern-in-android for sanity.

2. The Goetz et al reading describes threading issues for Java Swing, a GUI SDK that many Java desktop applications use. The Android SDK also uses a single GUI thread. 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?

Android has Services (http://developer.android.com/guide/components/services.html) which run in the background (even if the user switches apps!). Sounds like Swing has a similar thing called the Executor, which is actually outside the Swing framework but it is what this article recommends for background processes.


Ryan Rho - 3/5/2013 20:36: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?

Generally speaking, yes, but it is not strictly followed. The Android SDK itself follows the MVC paradigm. User interfaces, which stand for views in MVC, are usually implemented with XML files with an interactive tool on Eclipse. If developers would like to create some custom views, they could add more XML files and extra classes that extend View class. Resources and Databases are provided with XML files or wrapper classes for database connection, which is a model. Lastly, controllers are provided with Activity classes since it connects between views and models, and handle events and user inputs.

However, Android SDK follows the MVC paradigm, it does not enforce the developers to use it. Technically, developers can implement their applications without limiting the MVC paradigm. The developers could implement all models, views, controllers into one single class, or users don't have to use XML files to define user interface of an application. I believe a reason Android SDK gives you some freedom is that not all application may be suitable for MVC paradigm. For example, if you create a simple application that does not need a further maintenance, following the MVC pattern may be more costly. In addition, there may be possible to appear a new paradigm that a developer wants to try, which may be suitable for that specific application.

2. The Goetz et al reading describes threading issues for Java Swing, a GUI SDK that many Java desktop applications use. The Android SDK also uses a single GUI thread. 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?

When it comes to GUI threading itself, Android SDK and Swing are similar except that Android SDK is more sensitive about consumption of power so that it would like to minimize unnecessary memory and processor usage. For example, Android has a method called onLowMemory() in Application class so that you could "release" memory or act a necessary action for GUI.

Android SDK provides developers several mechanisms to improve user experience on long-running executions and background threads. First of all, it provides a cancellation whenever the application is considered to be unresponsive. Whenever Android SDK believes that an app is unresponsive, it opens a dialog to ask for canceling or waiting for the app. Probably it would not be a great idea for developers to reply on this mechanism, it is better than the indefinitely unresponsive application.

One minor difference in handling an unresponsive application on Swing (in desktop) and Android is that both Swing and the desktop operating system both handle unresponsiveness. So in the worst case of long-running GUI tasks in Swing application, the desktop operating system will resolve the problem by turning off the application.

In addition, Android SDK encourages the usage of listeners more often. Some GUI implementation such as animations require multiple listeners, one for the start of an animation, another for the end of an animation so that it does not block the GUI single thread, but still can execute other methods independently. Although the listeners cannot handle GUI themselves, they can set flags or change status so that different animations can be executed after the current GUI task is done.

To sum up, when it comes to handling GUI on Android and Swing, they are pretty much similar except that Android is more optimized for mobile usage with limited resource.


Aarthi Ravi - 3/5/2013 23:44:53

The Android SDK attempts to follow the Model-View-Controller paradigm.The "Model" which is the data or the process corresponds to the user-defined classes to process the data. The "View" corresponds to the resources and layouts that are either raw images or layouts in XML.The class which extends the Activity class is the "Controller" and is the class which controls everything. For example,through this class, data is fetched initially from the model to display the View, events like touch events or text entry are received by the Controller and the Model & the View are updated whenever an event happens.

For background executions, Android SDK uses AsyncTask class that allows one to perform background operations and publish results on the UI in an easy manner without having to manipulate Threads/ Handler. But this can be used only for short operations. A Background Task can extend this class which provides functions like: a)onPreExecute() - invoked on UI thread before task is executed b)doInBackground(Params..) - invoked on the background thread immediately after the onPreExecute() method is completed c)onProgressUpdate(Progress..)- invoked on the UI thread to display feedback d)onPostExecute(Result)- invoked on the UI Thread after the background task is completed. In SWING, a BackgroundTask class is implemented by the user defined task where the compute method should be defined/implemented. The compute method corresponds to the doInBackground method of the AsyncTask of Android.

Both Android and Swing use classes like Executor, Future Task and ThreadPoolExecutor to perform long running tasks. a) An Executor is normally used instead of explicitly creating threads. For example, rather than invoking new Thread(new(RunnableTask())).start() for each of a set of tasks, you can use an object of Executor class. b)ThreadPoolExecutor is used to execute multiple asynchronous jobs. c)The FutureTask provides an additional function cancel() to cancel a task


Shujing Zhang - 3/5/2013 23:47:50

1. Yes. First of all, model objects encapsulate the data specific to an application and define the logic and computation that manipulate and process that data. So any class that implements application logic is model objects. Second, since a view object is an object in an application that users can see, it can be applied to layout, resources and built-in classes like Button derived from android.view.View class. Finally, a controller object acts as an intermediary between one or more of an application’s view objects and one or more of its model objects. It applies to the activity class.

2. In android SDK, all components of the same application run in the same process and thread (called the "main" thread). All components in an application start within the same process and uses the same thread of execution. However, you can arrange for different components in your application to run in separate processes, and you can create additional threads for any process. For background threads and long-running tasks, AsyncTask allows you to perform asynchronous work on your user interface. It performs the blocking operations in a worker thread and then publishes the results on the UI thread, without requiring you to handle threads and/or handlers yourself. You can use AsyncTask and implement doInBackground() method, to update UI, you can implement onPostExecute().You can then run the task by calling execute() from the UI thread.

Both Java swing and Android SDK are running single thread with regard to GUI SDK. The views in android is very similar to the Components. However, Swing uses Event Dispatching Thread (EDT) for single thread model. Android uses XML for the View structure and layout instead of layout managers and component classes. In addition, Android use Intents instead of action events to send messages.


Yong Hoon Lee - 3/6/2013 0:19:47

1. The Android SDK does follow the MVC paradigm, somewhat. The layout files along with the View classes correspond to the View, the Activity classes correspond to the controller, and the various files inside the res folder as well as external databases which one can connect to the application correspond to the model. However, where this breaks down is in the view and controller, as the two are not as separated as in the classic MVC paradigm, as the controller interacts with the view in a very direct manner, as one points to the desired layout object directly. This is in violation of MVC, as in MVC, the view and controller should be separated. Indeed, the view should contact the controller when an event occurs, and the controller should contact the view to update when necessary. In the Android SDK, however, the controller and view work together to listen for events and update the layout that the user sees. Hence, you cannot use the same controller for different views without major modifications. However, the model is indeed separated from the view and controller, so the Android SDK does adhere to this portion of MVC directly.

2. android.os.AsyncTask provides one way to deal with background threads and long-running executions. This class is specifically designed to perform such tasks in the background, while updating the UI as desired. This class provides a doInBackground method which runs the code in a background thread, and uses the publishProgress and onProgressUpdate methods in order to update the GUI when the progress should be updated. It also provides a cancel method in order to cancel the thread which is being executed and utilizes an onCancelled method which is similar to the cleanUpPartialWork method presented by Goetz. This mechanism works very similarly to the tools for the Swing SDK described by Goetz, and utilizes the same threading mechanisms. However, the API for AsyncTask states that it is not designed to be used for very long operations (more than a few seconds), as it is a helper to Thread and Handler, and not actually a threading framework. Instead, the Google API suggests the java.util.concurrent APIs for longer operations. These frameworks are more complete thread handlers, and make use of the standard Java Runnable, Executor, and Future classes.


Brent Batas - 3/6/2013 1:11:09

1)

The Android SDK is pretty similar to the Model-View-Controller paradigm. The View class corresponds to the view, which users can see and interact with. The Activity class corresponds to the controller, which interprets users’ interactions with views, as well as tells other classes about changes in a view or model. The Content Provider class corresponds to the model, which contains data structures, as well as other code for managing/manipulating that data, apart from how it is presented (which is the view’s job).

2)

When an Android app is run, the system creates a new process for it, and all components of the application run in that process. The system tries to keep these processes running as long as possible, so that if the app is run again, it will reuse the old process. However, if the system needs to free up memory, it will terminate processes starting with the least important first, based on the components of the process.

Regarding threads, when an Android app is run, a “main” thread is created. This is essentially responsible for handling UI events, and so it is important that this thread is not blocked. Worker threads (background threads) should be used to perform any operations that are not instantaneous, in order to keep the UI responsive.

This is similar to the Java Swing GUI SDK, which is single threaded with the Main() method, and uses background threads (SwingWorkers) to run expensive tasks to keep the UI thread lightweight and responsive.


Annie (Eun Sun) Shin - 3/6/2013 1:14:05

1. Android SDK does not exactly follow the Model-View-Controller paradigm. It follows it loosely. For example, the model is what to render (classes implementing logic), the view is how to render (layout, Button, etc), and the controller consists of events and user inputs. However, it is unclear if the Android Activity class is a controller or a view because it handles displaying a window and the events of that window. Furthermore, with the Android SDK, the activity is the main entry point of most applications, instead of the controller (as it should be in a MVC model). 2. In the Android system, components of same application run in the same process and thread, but different components in an application can be arranged to run in separate processes, and additional threads for any processes can be created. Processes are placed into a hierarchy (according to the components running in the process and the state of these components), which determines which processes will be kept or killed. Threads can be implemented to be thread-safe if they might get called from more than one thread. Also, the AsyncTask object makes work easier for developers so that they do not have to handle threads and/or handlers themselves. Meanwhile, the Swing mechanism shares some similarities and differences. Processing long-running tasks consists of creating an Executor. The execution of tasks can alternate between the event thread and the background thread, a type of handling of long-running tasks called "thread hopping." For example, if there are three sequential subtasks, then the first subtask updates the user interface to show that a longrunning operation has begun and starts the second subtask in a background thread. Once the second subtask is completed, it queues the third subtask to run again in the event thread. There are also thread-safe data models similar to the Android SDK's threads ability to be thread-safe. In the GUI framework, presentation-related code runs as tasks in an event thread, and long-running tasks are executed in background threads.


Joyce Liu - 3/6/2013 1:59:28

1) The Android SDK does somewhat follow the Model-View-Controller (MVC) paradigm. The Activity class acts like the View and Controller. Activity is like the View because it displays data from the application’s Model objects to enable editing of that data, which is what an Activity does. More specifically, the View is like the XML layout and the Event Listeners because the View can respond to user actions, which is precisely what event listeners do. I think that the View class in the Android SDK would be the Model in the MVC paradigm because when a model object changes, it notifies a controller object which updates the appropriate view objects. The View class includes subclasses such as TextView, which can be changed. The Android SDK is somewhat different because what the Controller is exactly is complicated. The Controller is supposed to be the main entry point for the application, which would be the Activity in most instances, but in the MVC paradigm there the View and Controller should be separate entities, which means that the Android SDK does not exactly follow the MVC paradigm.


2) In Swing, we create our own Executor for processing long-running tasks. It has a cached thread pool. An action listener submits a long-running task to an Executor. In Swing, you can’t access presentation objects from the background thread, so on completion the task must submit another task to run in the event thread to update the user interface, involving adding layers of inner classes. The reading explains how the first subtask updates the UI to show that a long running operation has begun and starts the second subtask in a background thread. Once the first subtask finishes, the second subtask queues the third to run again in the event thread. Swing can also use a Future to represent a long-running task. FutureTask has a done hook that facilitates completion notification. Long-running tasks in Swing should be executed in background threads. The way that long-running executions are handled is similar in Android. For these long-running tasks, you usually put them in “background” or “worker” threads. There is also AsyncTask, which allows asynchronous work to be performed on the user interface. As the Android documentation describes, it performs the blocking operations in a worker thread and then publishes the results on the UI thread. The functions in Android that can help with threads are Activity.runOnUiThread(Runnable), View.post(Runnable), View.postDelayed(Runnable, long). When using the subclass AsyncTask, you need to implement the doInBackground() callback method, onPreExecute(), onPostExecute(), publishProgress(), and onProgressUpdate().


Christina Hang - 3/6/2013 2:14:30

The Android SDK does follow the MVC model in certain ways, but the Model and Controller layers are not completely separate. Firstly, the layout xml files of the Android in which the developer lays out the components of each screen corresponds to the views. In the layout files, the developer adds buttons, text inputs, menus, and other user input components that the user can see and can interact with. When the user pushes a button or selects a menu item, actions specified in the controller change the view accordingly. I say that the model and controller layers are not completely separate, because both are in some ways incorporated into every extended Activity class. In these classes, the methods linked to the view components act as the controller and model where the data is processed and the views changed according. Android has its own Thread class that manages the execution of the code and it can be running in the background. There is a system of priorities and several threads are used for “housekeeping”. Similar to Swing, Android also has event listeners that notify when data has changed. However, Android does not have frameworks like FutureTask and Executor like Swing to run in background threads.


Brian L. Chang - 3/6/2013 2:18:26

Yes, the Android SDK roughly follows the MVC paradigm. The views are roughly the xml layouts, the controllers can be seen as the activities that run in between the model and the view, and you can create many classes with different relationships in the android SDK for the models.

    Android has some similar functions to Swing that can help with long-running executions like onCompletion/onCompletion. Swing also has a onCompletion function that can execute when a task finishes. Android also has asynchronous tasks that can be run and be canceled when needed just like how tasks can be canceled in Swing. All in all, Goetz describes a few more ways that can help with long-running executions and threads and Android has many similar tools in different forms to address these issues in addition to the ones mentioned above.
   


Lishan Zhang - 3/6/2013 3:19:45

1. Yes, Android SDK follows the MVC paradigm.

Model: In Android, models are usually implemented as classes. We can build as many classes as we can for the model. Also we can override some of the classes that already written with our own purposes.

View: Android provides the users with resources and layouts like raw data files and layouts in XML. These views indicate exactly what the views look like and how they lay out.

Controller: Android use Activities to express controller which interact with the views. The SDK handle events in the Activities and then the activities build the view through the information from model and set up event handler to deal with the tasks.

2. To perform single GUI thread in Android SDK, we use “AsyncTask” which can take care of thread management for us.

AsyncTask enables proper and easy way to use UI thread. It can perform background operations and publish results on the UI thread without manipulating threads or handlers.

AsyncTask is ideal for short operations. If we need to run a long period of time, we should use APIs like Executor, ThreadPoolExecutor and FutureTask by java.util.concurrent. Otherwise it may block the entire user interface and no event would be dispatched.

An asynchronous task is defined by a computation which runs on a background thread and whose result is published on the UI thread.

When an application is launched, the system creates a thread called “main” thread that is the known as UI thread. UI thread is responsible for dispatching events to the appropriate views and interacts with running components of application’s UI.

Besides, we can also create a new thread and implements its run method for long time operations.

Similarity:

  • UI frameworks are single threaded for both Android and Swing.
  • AsyncTask in Android is similar to SwingWorker in Java Swing.
  • The mechanism for handling events from views in Android is so similar to Swing.
  • They are both not thread safety and must be manipulated on UI thread.
  • Long running operations should be considered.


Differences:

  • There are some new methods in Android like runOnUiThread, AsyncTack.
  • Does user allow background services.




Kevin Liang - 3/6/2013 4:05:00

1) Indeed it does. The views are done in the XML files. Each view has its own XML file. Models can be looked at like classes. For example extending something like ListActivity or TabActivity are examples. Finally the controller methods are defined in the activity files too. For example dealing with user events, capturing events are done separately and independently in a controller-like fashion as part of the MVC paradigm.

2) Android provides cancellation, progress and complete indication, and the SwingWorker. progress/complete indication and cancellation are pretty self-explanatory given their names. SwingWorker on the other hand is not as self-explanatory. SwingWorker is when you need to perform a long-running task but also need to update the UI when the process is in progress or when completed. It is similar to Swing mechanisms in a sense that they are implemented using the SwingWorker class. According to the article, "Swing makes it easy to have a task run in the event thread, but doesn't provide any mechanism for helping GUI tasks execute code in other threads". Although it somewhat is like swing in a sense that it runs on a single thread, except it runs on a different thread of its own since it is a long running task.


Sihyun Park - 3/6/2013 5:23:38

1. Unlike its counterpart, iOS, Android does not strictly follow a Model-View-Controller paradigm. Whereas the model (class) contains the business logic and the view (UI - i.e. XML files) contains the interface, the controller equivalent in Android - Activity - both presents the interface and handles the events happening in the window. Instead, it's more like Model-View-Presenter, in which view both presents the interface and handles the events, and activity will be a part of the view. Presenter will be a separate class that handles communication between the model and the view, querying the model and updating the view if necessary. This can be (though not the only way) done using Adapter classes in Android.

2. For long-running executions and background threads, the developer must not block the UI thread and not access the Android UI toolkit from outside the UI thread. As such, the developer can use a worker thread to perform jobs in background without blocking the UI thread. To manipulate the UI from a worker thread, the developer can use runOnUIThread(Runnable), post(Runnable), or postDelayed(Runnable, long). However, as this can be cumbersome in some complex tasks, the developer can use AsyncTask instead. To use AsyncTask, the developer must subclass from AsyncTask and implement the doInBackground() method, where the background tasks will be implemented. To define the actions taken to update the UI, define the onPostExecute() method. Both Swing and Android is similar in that they both support multi-thread operations, but have a single main thread for event dispatching - EDT (event dispatching thread) for Swing, and UI thread for Android. They both support asynchronous messaging mechanisms as well.


Tenzin Nyima - 3/6/2013 8:57:19

1) In particular, Android doesn’t have a solid architectural approach. But one can definitely build applications using paradigms such as MVC (Model-View-Controller). In android, Activity is the main entry point and everything start within onCreate method in the Activity. As we know, views are being instantiated once the onCreate method is being called. Similarly, we can certainly instantiate model and controller in the onCreate method. As with other platforms that follows MVC paradigm, controller can now get reference from model and communicate to the view. In summary, Android applications can definitely be built using MVC paradigm where layouts correspond to views, classes correspond to models and activities correspond to controllers.

2) According to Android documentation, AsyncTask enables proper and easy use of the UI thread. The document further mentioned that the same class (AsyncTask) allows developer to perform background operations. But AsyncTask is not ideal for long-running threads. The documentation says, “If you need to keep threads running for long periods of time, it is highly recommended you use the various APIs provided by the java.util.concurrent package such as Executor, ThreadPoolExecutor and FutureTask.” The mechanism of long-running threads in Java Swing, as described in the reading, is very similar to that of Android’s. Goetz et al writes that GUI applications like Java Swing are nearly implemented as single thread subsystems but we can create our own Executer for processing long-running tasks. As I said above, android’s documentation recommended you to use the Executer as well. Therefore, I conclude that, when it comes to the implementation of long-running and background threads, in both android and GUI application like Java Swing, you can always implement long-running and background thread by building helper classes.


yunrui zhang - 3/6/2013 9:05:30

I don't think that the Android SDK follow the Model-View-Controller paradigm. Normally one would propose that the xml files is the view and an activity is a controller. But a MVC paradigm separate the view and the controller, and in android one cannot instantiate an activity without talking to the layout. The android prefers inheritance over composition.

2.Android have Worker Thread and Async Task mechanism that helps handle long operations. Worker thread has methods like Acitivity.runOnUiThread(Runnable), View.post(Runnbale),View.postDelayed(Runnable,long), and AsyncTask has methods like doInBackground(), onPostExecute() to help developers with long-running executions and background threads. They are very similar to the Swing mechanisms.


Bryan Pine - 3/6/2013 9:08:13

1) The Android SDK is close to the model-view-controller model, but has a few differences. The .xml file basically corresponds to a view, and the java activity files are kind of controller and model rolled into one. The main reason that Android SDK varies from the model-view-controller concept is that the view does not exist independently of the model/controller. A true model-view-controller application would have a model that would be interchangeable between views provided those views used the proper access methods. Android's activities come attached to a view, so although they behave like both model and controller in a given application, they are not interchangeable.

2) Long-running executions and background threads in Android SDK are handled similarly to Swing. In Android, something called a Handler interposes between the main thread and background threads and queues up messages for the main thread to pop one by one and execute (by updating the UI). You can use handler.sendMessage() or one of many variations to have a handler send an update to the main thread. The main thread uses a Looper object to actually go through the queue and get the messages. The queuing concept is pretty much what Swing does with it's background threads except that Android SDK has these pre-defined classes that handle the message sending and queue looping rather than making the user implement them with each new thread.


Bryan Pine (2) - 3/6/2013 9:09:29

Last one is still my response, but here is my source for the second question: http://www.aviyehuda.com/blog/2010/12/20/android-multithreading-in-a-ui-environment/


Glenn Sugden - 3/6/2013 10:17:21

You can squeeze the MVC pattern out of the Android SDK but the results aren't very pretty. The most straightforward portion, the model, shouldn't rely on the Android SDK very much at all, instead favoring plain old Java to do the heavy lifting (and therefore testable sans SDK with something like JUnit) while possibly sprinkling in any necessary utility functionality from the SDK. The view/controller is a bit more tricky, as they are (initially) intertwined with each other in the form of "Activities." However, I discovered that you can actually tease apart the view from the controller if you strictly relegate the Activity to be the controller, and associate the .xml (layout) files with a different view class. At the beginning of a layout, apparently you can specify a class (E.G. edu.berkeley.CS160.GS.views.MainView) and then associate the java class with the Layout (E.G. MainView extends LinearLayout {} ) Using these techniques it is possible to (strictly) MVC your Android app, but it requires some work and a lot of discipline.

The two threading models are very similar, as Android follows the "UI on the UI event queue" scheme, while borrowing heavily from the Swing functionality of interacting with additional (background) threads. Both have mechanisms to start tasks on the main GUI/Event thread, while each has a slightly different way to start/manage/end tasks on different threads. Swing provides some basic, low-level functionality in it's SwingUtilities class: isEventDispatchThread, invokeLater, and invokeAndWait. This are similar to Android's Activity.runOnUiThread and the View's post and postDelayed methods, although each have somewhat different characteristics (E.G. invokeLater runs "when it's convenient," while postDelayed allows the developer to specify a time to delay before running the task/thread). Beyond that, Swing and Android have a few vague similarities with their structure (E.G. AsyncTask vs. SwingUtilities & Executor) but are really more specialized versions that are appropriate for each framework (E.G. Android RPCs would be better handled by Java's RMI technology for Swing components).


Michael Flater - 3/6/2013 10:34:33

Android does follow the MVC paradigm. There is the layout, or View, the MainActivity java code, which functions as the Model. MainActivity can also function as the View, if one so desired, by using java functions instead of XML. This is not a perfect fit, of course, since there is no distinct separation between the Model and the Controller as there is in, say, Ruby on Rails and the like. The Controller acts more through intents than through a solid java class.

Since Android SDK and Swing both use Java, the same implementations are likely to work for both. To be perfectly honest, this question makes little sense. I have been using the Android SDK for five weeks, I don't know enough about it to answer this question with any level of accuracy, nor does a 15 page document give me enough knowledge about Swing to compare the two.



Jin Ryu - 3/6/2013 10:43:39

1. Yes, the Android SDK also follows the Model-View-Controller paradigm. Its layout files in XML correspond to the View while its other resources such as string, images, and other data can correspond as Model Objects. The layout determines the graphical view that the user sees and interacts with such as text input or any buttons they can press. This layout file is decoupled from its other resources folders and XML files that holds strings, values, images, and etcetera, which are the application's data that will be used but cannot be changed by the user without going through the controller. The Controller Object in Android SDK is represented by the actual java code behind the application (source files) that can manipulate both View and Model.

2. Android has only one main UI thread but uses separate worker or background threads to handle longer processes. They are safe as long as it is not accessed outside of the Android UI thread and the UI thread is not blocked. This is similar to the Swing mechanisms in that it has the single-thread rule of all components and models should be created, executed, and called only from the single event thread. Android SDK give several methods to access the UI thread from outside that are: Activity.runOnUiThread(Runnable), View.post(Runnable), and View.postDelayed(Runnable, long). It is similar to the BackgroundTask used in Java Swing. Android SDK also has an AsyncTask that allows blocking operations in a separate worker/background thread which is passed to the UI thread once finished. The AsyncTask can be cancelled at any time from any thread, and it has methods such as publishProgress(), onPreExecute(), onPostExecute(), and onProgressUpdate() which executes on the UI thread so that the application can remain interactive and responsive. This may be similar to BackgroundTask and SwingWorker in Java Swing that these classes also takes care of these techniques such as allowing for cancellation, completion notification, and progress indication.


Matthew Chang - 3/6/2013 11:11:57

1) The Android SDK lends itself toward something like the Model-View-Controller paradigm but does not necessarily enforce all of the concepts. The clearest connection are that the views in an mvc paradigm correspond with the xml layouts and the controller correspond with the Activities where the most of the logic for apps are made. The biggest difficult is in the use of models. My past experience has been with the MVC paradigm used in Django, which may be skewing my expectations for the paradigm, but with Activities, there doesn't appear to be an equivalent for a model. Models are intended to abstract away common queries for information made to some data source, whether it is a web api or a database. After some quick googling, I determined that there are tutorials that do make use of a model paradigm, but it is not managed by the sdk and it is an abstraction that was introduced for the purposes of making the tutorial easier to understand.

2) To handle long-running executions and background threads, the Android SDK provides basic threading as well as managed threads such as AsyncTask. AsyncTask can be seen as a special thread that has been wrapped to make it easier to interact with and manage. In Swing, they have a similar implementation called SwingWorker that also surfaces many of the same functionality present in AsyncTask. They provide easy to fill in methods for specifying the task to be executed, provide feedback to the user in regards to progress, as well as provide feedback to the user upon completion of the task.


Marco Grigolo - 3/6/2013 11:30:54

1. Android does not follow the MVC pattern. While View and XML files to define how an activity should look like is pretty much a View, and an Activity itself might be considered a Controller, model are missing. Instead we have the views, and Activities are an hybrid between Controllers and Models, since they store the information used by the Views, allow (upon events) modifications on such data, and might even transfer control to other activities.

2. Android and Swing both make use of AsyncTask to handle long running tasks (such as a response from a server). Moreover, when task might need long time to complete, both Android and Swing usually provide a visual feedback about the fact that the machine is processing/waiting the information to complete the task. In the case of Android (and iOS for that matter) we can have a Spinner (usually on the bar, so it does not interfere with the other activities), while for Swing we can have completion bars (that unlike android would interfere with other functions since they would be displayed in the top view) as well as a spinner that might run in a side view.


Moshe Leon - 3/6/2013 11:35:13

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? MVC is a concept which can be adopted by any framework that wishes to implement it. All you have to insure is that a MODEL sets the templates and what to render, the VIEW deals with the visualization of the GUI and sets the way things are rendered, and the CONTROLLER is the messenger which carries the user input, and ‘knows’ about the events that occur. To further explain- in order to keep a proper MVC one has to insure that view and data do not get mixed, and views would have the responsibility of just holding user data or instantiated classes, which in turn are responsible for processing the data, which eventually sets the view. If the views and the Layouts are defined in the XML file, the resources are loaded from the RES folder, and views and models don’t mix, then it is almost following the MVC model. However, the way Android handles it, MVC could be violated if the programmer does not care of MVC implementation. If it follows the MVC then an Activity is like the CONTROLLER, a MODEL is the classes and the VIEW is the layout and the xml files. If it does not follow the MVC, then the Activity does more than what it is supposed to do, and there is a mix-up between responsibilities of the MVC definitions. Classes (as the model) are supposed to be used as models for instances, and should be as far as possible from any activities.

2. The Goetz et al reading describes threading issues for Java Swing, a GUI SDK that many Java desktop applications use. The Android SDK also uses a single GUI thread. 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? Android uses a Single thread model for UI toolkit- which is NOT thread-safe. This is a good reason to NOT block the UI thread and not to access the UI toolkit from outside the UI thread. One of the methods to run Multi-Thread code is: A Thread worker object: t = new Thread(new Runnable() ) , but due to unexpected behavior, there are a few methods to ‘put a leash’ on it, and get a more ‘thread safe environment’: Activity.runOnUiThread(Runnable), View.post(Runnable) and View.postDelayed(Runnable, long). Last one is AsyncTask (which is similar to SwingWorker) which allows the programmer to perform asynchronous work on the user interface, and performs blocking operations in the worker Thread (publishes the results on the UI thread) and thus saves the programmer from having to handle these operations on his own. To name a few more possibly (they need to be properly implemented first) ‘thread safe’ methods- onBind(), query(), insert(), delete(), update(), getType() can be called from a thread-pool. The AsyncTask is similar to the SwingWorker, and runOnUiThread is a new method. The knowledge from the Swing multi-threaded apps was transferred and perfected in some ways within the Android SDK. Android app could be a lot simpler, and thus require less synchronization. The swing relies on Executors to do background work (which is normally heavy- unlike Android). Any Swing app is multi-threaded by nature, unlike Android. So Swing is similar to Android, but Android took the threading another step forward.


Cory Chen - 3/6/2013 11:43:53

1. The Android SDK seems to also use the Model-View-Controller paradigm. You define the view (user interface) through xml layout files, the model could be the classes that include the functions, and the controller could be the individual activities.

2. The Android SDK makes GUI elements work in a single thread, but it gives you a few resources to deal with long tasks. When you have a task that needs to go on for a while, Android allows you to make a worker thread that will perform the task and allow the UI thread to move forward. Improving upon the worker thread implementation, Android also gives us the AsyncTask. It performs the worker thread task and gives the result to the UI thread, and handles all of the complicated threading for you.


Samir Makhani - 3/6/2013 11:49:20

1.) The Android SDK follows the MVC paradigm. Not as advertised as the iPhone SDK, but more implicitly. Activities on the Android SDK, which are subclasses of the activity class, has the capacity to generate events and accept user input. Thus, activities in android SD works as the "controller" of the MVC by responding to events and managing the flow of views. Models in the android SDK are managed through the use of ContentProviders, which are objects that allow the programmer to manage persistent data. Essentially, on the android SDK, models are the classes that implement the application logic. Views are the XML layouts, as well as other resources and built-in classes like Button that are derived from Android.view.view. Thus, the MVC is implicitly built in to the android interface.

2.) Android has a couple of objects called AsyncTask and Progress Dialog that greatly helps developers with long-running executions and background threads. AsyncTask allows for proper and simple use of the UI thread. In a nutshell, this class/object allows developers to perform background operations and publish results on the UI thread without having to manipulate threads.Progress dialog will allow the developer to have an indicator/view for the progress of the background threads and long-running executions.Java Swing has similar mechanisms such as SwingWorker, which implements java.util.concurrent.Future, which allows the background task to provide a return value to the other thread. Other methods in this interface allow permit cancellation of background task, and discovering the progress of the task.


Sumer Joshi - 3/6/2013 11:53:23

2) Some of the functions, objects, and mechanisms in Android are doing mouse-clicking events, running different tasks more than once, etc. Android objects could be considered as layouts, or objects that are being passed into the Activity. Swing mechanisms usually have the run() method located inside of the model, which would indicate that a thread(s) are being run in order to have multiple states running at the same time.

1) Android SDK follows the MVC paradigm Model: What is being Rendered? Activity View: View method in Android that shows what happens after a mouse-click and drag for example (View Class) Controller: Events, Input from User


Eric Wishart - 3/6/2013 12:01:47

1. The Android SDK follows the MVC paradigm to some extent. The View is represented by the layouts built in classes like Button which is inherited from android.view.View. The Controller is the activity that you are running, and the Model is the set of classes that you have written to handle the application logic.

2. To help Android developers with long-running executions and background threads we have several functions which give us the ability to cancel or do other things while we wait for completion.


Swingutitilies contains several fields that give us needed information. Among them are isEventDispatchThread, invokeLater, and invokeAndWait. Additionally there are methods that can enqueue a repaint or a revalidation request on the event queue and some methods for adding and removing listeners.

Android has similar functions with View.postDelayed(Runnable, long), Activity.runOnUiThread, onProgressUpdate, and publishProgress(). These functions and Objects allow for the same functionality as the Swing mechanisms, just in a slightly abstracted way.


Thomas Yun - 3/6/2013 12:06:59

I think that the android SDK closely follows the model-view-controller paradigm. In my opinion, the model is the object itself, such as the object class, the view is what the users see when the model is modified, and the controller is the input basically or maybe a code that modifies the model which in turn notifies for the view to be modified. Using the drawing application as an example again, I would say that the canvas object would be the model, the view would be how the object changes with user input, and the controller is basically the user making motions on the canvas. Or maybe the model could be a button class, the view could be the state of the button(if it is pushed down or not) and the controller is again the input. I think that a lot of things follow this paradigm especially the GUI ones because there is obviously a view that users can see.

I actually have some experience with java threading so there are problems that I have encountered that are mentioned in the reading. One thing for sure is that drawing has to be done on the main/event thread or there are risks with having problems. While quick tasks wouldn't require a separate thread, long running tasks (even infinite looping tasks) would definitely need a separate thread (especially if it is running infinitely). Thus long running tasks would require a separate thread and there are certain methods that can be called with them such as futuretask. To help with threading, there is the executor class which assigns tasks to random threads and adjust the necessary amount of threads needed so the user wouldn't have to actually define that number of threads they need. As an example, in my java app, I drew a lot of buttons on the screen and for each button, I run in a separate thread a function that constantly checks if the button is pressed within a certain time frame at a certain time in that frame and if it is, a calculation is run. Sometimes, this leads up to about 100 threads per time frame. Basically, you wouldn't want the program to freeze up every time a button is drawn and a thread is run because it defeats the purpose. With that, Android should be similar to Swing as they are both GUI based to some extent. Although threading may be limited per device, they should both perform threading in a similar way.


Christine Loh - 3/6/2013 12:10:39

1. I believe that the Android SDK does follow the Model-View-Controller paradigm; you have your user interface in different XML files so the view and the controller could be encompassed by the Activity. You can then create any classes within the development for the model.

2. For the Swing event, it's somewhat of a single thread executor that processes threads from an event queue, short-lived. Similarly, the Android SDK has an application process and removes old processes to reclaim memory for new processes or ones with higher priority. It sets the process into an importance hierarchy based on what components it has and their states, and eliminates the ones of least importance.


Yuliang Guan - 3/6/2013 12:25:04

(1) Yes, the Android SDK follows the Model-View-Controller paradigm. The model object encapsulates the data specific to an application and define the logic and computation that manipulate and process that data. In Android, Model is like the subclass of an application. Based on my understanding, we can set up a centralized data model in Android so that all activities have access to. A view object is an object in an application that users can see. In Android, it is anything that subclasses view. Controller objects acts as an intermediary between one or more of an application’s view objects and one or more of its model objects. Controller is activity in Android. When users make an action, the controller will interprets the actions made in view objects and communicates new or changed data to the model layer. When an activity gets focus, it will be required to draw views. Controller objects greatly simplifies implementing GUI applications.

(2) GUI applications may execute tasks that may take longer than the user is willing to wait. These tasks are long-running executions run in another thread so that the GUI remains responsive while they run. Swing makes it easy to have a task run in the event thread, but does not offer any mechanism to help GUI tasks execute code in other threads. Meanwhile, by having done trigger a completion task in the event thread, a BackgroundTask class can be constructed. BackgroundTask also supports progress indication. Actually, a framework using FutureTask and Executor to execute long-running tasks in background threads has been built. These techniques can be applied to any single-threaded GUI framework, like Android, but not just Swing. From this point, I think the functions, objects and mechanisms in Android are similar to the Swing.


Tiffany Lee - 3/6/2013 12:26:05

1) The android SDK gives a lot of freedom to the programmer as to how they want to model their code. If the user so chooses to follow a MVC paradigm, he or she can by separating the their classes into the respective Model, View, and Controller classes. Android's XML files and View classes can be considered as the View. The programmer can use Activity classes as the Controller and Database classes as the model. Android SDK has a lot of other classes that could also be used to help with the MVC paradigm.

2) For background threads, Android offers the AsyncTask class. The Android Document states: "An asynchronous task is defined by a computation that runs on a background thread and whose result is published on the UI thread." However this class is best for short-running tasks; for long-running tasks concurrent threading is recommended. The concurrent package in the Android SDK offers classes that help deal with long-running tasks. Classes such as Executor, ThreadPoolExecutor, and FutureTask can be used. These tools the Android SDK has to offer, offer similar tools as Swing. For example, both have Executor and FutureTask classes that do similar things. Both also have cached threads.


Nadine Salter - 3/6/2013 12:36:52

Android's SDK follows the MVC paradigm, after a fashion -- for example, the ListView interface component (view) is backed by an Adapter that queries a datastore (model) and issues state updates to listeners in an Activity that then take further action (controller). In the general case, views are created in XML or code, models are custom classes with their own database functionality, and controllers are spread throughout code in the Activity and helper classes. While controller code can be localised to one single Activity class as much as possible, the abstraction is imperfect: Activities cannot function independently, as the controller code is tightly bound to the corresponding views.

Because Swing and Android are both built on Java, the same underlying classes are present in both -- it's possible to implement multithreading using Executors and Threads, just as in other Java toolkits. Android also provides its own helper classes, like AsyncTask, which appears to provide an analogue to the SwingUtilities functionality outlined in the reading; however, unlike the Swing mechanisms' "these methods are called by the developer" approach, developers implement desired functionality in AsyncTask and the frameworks then call one's custom class.


Elise McCallum - 3/6/2013 12:38:21

1. The Android SDK does follow the Model-View-Controller paradigm. The classes that correspond to the model are the data objects defined in Android. Often these are custom components defined in the Activity class, or other classes defined in the application to be used with data. The classes that correspond to the view are all the UI components defined in the given Android application (e.g. View, TextView, Button, etc.). The classes that correspond to the controller are the Activity classes, as they handle the interaction between the model and the view.

2.Android supports long-running executions and background threads by allowing each component element to set a process attribute. In this way, if a component is expected to be a long-running process, then it can operate in its own thread while other processes occupy different threads (sometimes shared), so that the long-running process can run in the background and not slow down the entire application. Android also implements a least recently used list to keep track of background processes (ones not currently visible to the user) to ensure that if a process is killed, it is the one least recently accessed by the user. This way, the user also will not be impacted visibly when a process is killed. To do this successfully, the main thread acts as a dispatcher so that when a button is pressed or text is submitted or another UI action is taken, that event is dispatched to the proper widget. This widget then posts an invalidate request, the main thread removes the request, and tells the widget to redraw itself. This way, not all the work must be done by the main thread. This is very similar to Swing mechanisms, such as the SwingWorker, in the way that it handles events from components. The event handling mechanism is nearly the same in Android and Swing. The idea behind having event-drive mechanisms is also shared cross Swing and Android.


Weishu Xu - 3/6/2013 12:47:18

1. The Android SDK sometimes follows the Model-View-Controller paradigm, but it varies with the application. Some applications like games have a clear "Model" object that controls the data. However, many applications are designed to be like a tool that does not have a specific "player" or item that acts or has actions done to it. Many times, the application works with a View object that captures state and displays data. Many times the View does the computation and there is not a direct need for a Model object that should be tracked. When there is a Model object, there may also be a controller object that manages how the View changes or Activities change in the Android SDK. These should be objects such as "onclicklisteners" that manage how the application changes based on input and switches between different views.

2. For long-running executions and background threads, Android offers tools such as AsyncTask that can offer threadhandling with methods such as doInBackground() and execute(). This is similar to how Swing offers a BackgroundTask class. AsyncTask also offers task cancellation.


Timothy Ko - 3/6/2013 12:54:18

The Android SDK doesn’t seem to follow the Model-View-Controller paradigm too strictly. Rather it seems to have two segments: the view and the model/controller, at least for the applications that I have worked on. The view consists of all the layouts of your different activities, which shows the actual interface that the user will see. These are usually written in xml files. The model/controller consists of the activity java classes. This is where all the logic of translating user initiated events to change the model is located, which would make the activity java classes the controller objects However, this also seems to be where all the data is, which means these java files are essentially the model object as well. So rather than have a three part paradigm, Android SDK seems to support a two part paradigm.

Long running tasks can be handled using a class called ASyncTask. Similar to Future’s in Swing, ASyncTasks simplify the process of putting long running tasks in background threads. They even have methods for updating progress and cancelling tasks. This is all similar to how Swing handles long running tasks and background threads.


Andrew Gealy - 3/6/2013 12:54:46

It's not clear if the Android SDK forces the MVC paradigm, but parts of it could be interpreted to match. The View consists of XML layouts and the view objects they specify. The Controller is represented by Activity code. The Model is represented by other Java data structures. It is less clear to me how the Model and Controller portions are differentiated, as it seems as though Activities can contain all of your data without maintaining any sort of abstraction barrier.

Meta-Question: How are we supposed to be answering questions like #2? My knowledge of the Android SDK obviously does not encompass tools for managing background threads; am I supposed to Google the answer?

ASyncTask is an object that allows running of short term background operations in the order of a few seconds while allowing progress updates to the GUI thread. Services can be used to run longer operations in the background without accessing the GUI. It seems from the reading as though Swing includes little in the way of built-in background thread management beyond the single GUI thread, but does allow for the user to construct his own tools.


Kate Gorman - 3/6/2013 12:57:04

Android can follow the MVC, if the user decides to implement it this way. One way this might occur is that the OnClick classes are the controller. This will send updates to the model, which would be any other code within an Activity. And the main of the activity would be the view, which just receives updates from the model. However, in practice, I think Android combines the View and the Model in that the controllers are part of the Android SDK and allow intercepting input from the user, but the model and the view are almost one in the same in the Activity.

2. To handle long-runnning processes like web services calls, one can utilize the AsyncTask class in android, which allows for progress updates to the UI and the ability to cancel a process, all while running the process in the background, not on the main UI thread sequentially. This AsyncTask class is very similar to the mechanisms described in the reading for swing, except that the developer does not have to manually touch the threads, the AsyncTask class handles the implementation which reflects that of the Swing implementation in the reading.


Dennis Li - 3/6/2013 13:11:17

1. Yes. The view is obviously the different screens. The display is constantly changing in response to user input and interaction. The model is more ambiguous. One possible model could be the events and how the data from the events is processed and represented. I believe more strongly, however, that the model is the different activities. Each activity contains data and individual activities have relationships with each other depending on what the user interaction is. The controller is what links different activities. This varies from app to app and can be a button or simply a timer.

2. In android you are given methods such as doInBackground() that allow you to simultaneously perform calculations while doing other things with your GUI. Android also does have a Thread class that allows users to create new instances when they want to parallelize actions. These are quite similar to the Swing mechanisms because they really do do the same things. They work on side problems while a single GUI thread is updating the screen and processing user input.


John Sloan - 3/6/2013 13:14:12

1) The Android SDK does follow the model-view-controller paradigm. The controller is essentially android events and event listeners, that take in user input and send it to the model to decide what needs to be rendered in response. The model corresponds to any internal class you've created to deal with events. The view is then everything that uses to update what should be displayed, such as the xml layouts and view widgets. These are all updated by the model's classes.

2) Using AsyncTask is the best to deal with long-running executions and background threads in Android. Most importantly it has a doInBackground method that creates a new thread for whatever is contained in the method, separate from the main thread, and runs it in the background. This way GUI can continue to respond and update when longer tasks are being completed in the background. It also has methods for PreExecute, PostExecute, and onProgressUpdate that allow the GUI to update when progress is made and other tasks. This is very similar to the Swing mechanisms discussed in the reading. Swing allows for creating an executor in exactly the same way with a Background method or class, etc. According to the reading, these techniques can be applied to any single-threaded GUI framework and since Android is also single-threaded (as almost all GUI platforms are) it makes sense that it has similar mechanisms to that of Swing.


Tananun Songdechakraiwut - 3/6/2013 13:14:59

1. It is incorrect to state that Android SDK follows the Model-View-Controller paradigm, it, however, depends on how you want to build your UI. For the UI layout in Android, each component of an app is defined around View and ViewGroup objects. The ViewGroup objects is a container organizing their child views in a hierarchy. But that doesn't mean that Android SDK can't follow the Model-View-Controller Paradigm. Android SDK is pretty flexible and thus it is not necessary to build everything using only View and ViewGroup objects. This means that you can also follow the Model-View-Controller paradigm if you want to. Furthermore, Android also offers a standard UI layout for you such as Dialogs, Action Bar, etc.

2. So java provides Thread class which allows you to create worker/background threads with the interface Runnable and its method run(). However, Android has two rules; one of them is that "Do not access the Android UI toolkit from outside the UI thread". Violating the rule can easily result in bugs/glitches. So Android offers ways such as Activity.runOnUiThread(Runnable), View.post(Runnable), and View.postDelayed(Runnable, long) methods.For more detail, visit developer.android.com. These are simply the ways to access the main thread(called UI thread) from others.

Well, the logic behind is similar. Both use worker/background thread as a solution. In Swing, you create execution which then alternates between the event thread and the worker thread which is created simply from a cached thread pool. In particular, see Listing 9.5 on the article. Second subtask is done in a background thread. Third subtask is just a way to let the main thread(called event thread in the article) updates the UI to reflect the operation. Likewise, in Android, we create a worker thread and then use one of the three Android methods mentioned above to get back to UI thread.

Unlike in Android SDK, Swing doesn't provide any mechanism to help us about ways to have GUI tasks execute in other thread easily(only makes it easy for a task run in the main thread).


Tananun Songdechakraiwut - 3/6/2013 13:16:11

1. It is incorrect to state that Android SDK follows the Model-View-Controller paradigm, it, however, depends on how you want to build your UI. For the UI layout in Android, each component of an app is defined around View and ViewGroup objects. The ViewGroup objects is a container organizing their child views in a hierarchy. But that doesn't mean that Android SDK can't follow the Model-View-Controller Paradigm. Android SDK is pretty flexible and thus it is not necessary to build everything using only View and ViewGroup objects. This means that you can also follow the Model-View-Controller paradigm if you want to. Furthermore, Android also offers a standard UI layout for you such as Dialogs, Action Bar, etc.

2. So java provides Thread class which allows you to create worker/background threads with the interface Runnable and its method run(). However, Android has two rules; one of them is that "Do not access the Android UI toolkit from outside the UI thread". Violating the rule can easily result in bugs/glitches. So Android offers ways such as Activity.runOnUiThread(Runnable), View.post(Runnable), and View.postDelayed(Runnable, long) methods.For more detail, visit developer.android.com. These are simply the ways to access the main thread(called UI thread) from others.

Well, the logic behind is similar. Both use worker/background thread as a solution. In Swing, you create execution which then alternates between the event thread and the worker thread which is created simply from a cached thread pool. In particular, see Listing 9.5 on the article. Second subtask is done in a background thread. Third subtask is just a way to let the main thread(called event thread in the article) updates the UI to reflect the operation. Likewise, in Android, we create a worker thread and then use one of the three Android methods mentioned above to get back to UI thread.

Unlike in Android SDK, Swing doesn't provide any mechanism to help us about ways to have GUI tasks execute in other thread easily(only makes it easy for a task run in the main thread).


Linda Cai - 3/6/2013 13:23:16

The Android SDK follows the MVC paradigm, although it doesn't seem a central part of the SDK. Activity classes appear to behave as controllers, dealing with the UI, while the XML class definitions are the view, and ContentProvider classes are the Model.

Android provides a class called AsyncTask to manage a long-running or background task. This is similar to how Swing does things, with SwingWorker and BackgroundTask classes, which also manage the longrunning/background tasks.


Juntao Mao - 3/6/2013 13:24:35

1.Android SDK does follow. The controllers are the activities, the views are anything that extends the view class and the XML files that defines UI and resources, and the Models are the different classes in the application.

2. In Android SDK, when the app is started, one main thread is created in charge of dispatching events to the appropriate user interface widgets. With this UI thread, if any long processes is done on it, such as database access, the UI thread would be blocked, nd the performance would be poor. Therefore, if long processes are desired, start a worker thread. Noting that Android has a model: do not access the Android UI toolkit from outside the UI thread, therefore, there are methods:

  • Activity.runOnUiThread(Runnable)
  • View.post(Runnable)
  • View.postDelayed(Runnable, long)

Both the Android and Swing uses Runnables with different worker threads, but Swing has no specification about accessing UI elements. There is also the AsyncTask class for Android, which "performs the blocking operations in a worker thread and then publishes the results on the UI thread, without requiring you to handle threads and/or handlers yourself." Must implement doInBackground(), which runs pool of background threads, and onPostExecute() that delivers result from Background to UI thread, and then calling execute on UI thread runs the task.

Info for Android SDK from http://developer.android.com/guide/components/processes-and-threads.html.


David Seeto - 3/6/2013 13:24:44

At a higher level, the Android SDK does support the MVC paradigm. The model can be your data classes and content providers. You can declare something that is the subclass of Application in the manifest and it will persist despite the starting and ending of activities. The view can be defined by XML files and by subclasses of view objects. The controller are the activities that can react to events in the view or changes in the model. However, the distinct roles that these three parts of MVC can easily be intertwined in the SDK. For example, xml view objects can actually be defined in activities and along with the business logic and database. In this instance, all three distinct parts are actually all in one.

The Android framework provides many of the mechanisms that the other mentioned GUI's use for threading issues. They have an Executor, AsyncTask, ThreadPoolExecutor, FutureTask, and Services class. These classes accomplish things similar to the Java Swing framework mentioned in the reading, the reason probably being that they both use Java and that there is no reason to reinvent the wheel. These classes handle use of the UI thread, processing long-running tasks, using pooled thread to execute tasks, etc.


Erika Delk - 3/6/2013 13:27:36

1. The Android SDK roughly follows the Model-View-Controller paradigm. While the separation between the three components is not as clear as in some frame works (such as ruby on rails) you can separate some of the classes into the three components. In the Android SDK we could say that the layout and all of the widgets on it compose the view. All of the event handlers and listeners would be the controller. The model would then be all of the code that is written to control and save the data.

2. In Android, event listeners are used to "listen" for events by using a waiting loop. Swing, on the other hand, uses a cached thread pool to handle long running events. While these methods are different on a fundamental level, both methodologies do use event listeners.


Ben Goldberg - 3/6/2013 13:29:00

1) Yes.The XML files and the View class correspond to the View, the Model is made up of objects and data structures, and the Controller are the callback functions like OnClick.

2) There's the AsyncTask class which can create and run different threads in the background. You implement the doInBackground() method to do whatever task you want to run in the background. To update the UI thread with this work, you implement the onPostExecute() method.


Lauren Fratamico - 3/6/2013 13:31:46

1. MVC is a lose concept of how pieces should interact, not a unique pattern. The model is in charge of what to render, the view in charge of how to render, and the controller in charge of events and user input. Yes, Android SDK can follow the MVC framework, but it depends how you implement your project. For the most part, it doesn't seem like Android implements it inherently, you'd have to change how you structure your project to get it to do so. It seems like the Activity is both the View and the Controller. Models are implemented and you can create as many java classes as you want for those. If Activity was split up so that one handles just making the display and one handles the input, I'd say that it followed MVC more strictly. But since these two are intertwined, I think it mostly does not follow MVC.

2. The single threading issues are fairly similar to those observed in Java Swing. Each application is a single thread, so android tries to keep each thread alive for as long as it can before it needs to kill them to free some space. All alive threads are put in a priority queue. Those with lowest priority include background threads - though this is not the lowest priority (empty threads are). Background threads are run with lower priority and are killed with higher priority. Long running executions are similarly on the queue. If it runs for too long, and takes up too much memory, other threads may have to be terminated (potentially killing other applications). One can also change a few options in the manifest if they want different thread settings.


Raymond Lin - 3/6/2013 13:34:24

1. Yes the Android SDK follows the MVC paradigm. In terms of classes, anything that you choose to extend from the base View class can be considered a view, basically where the image is rendered. The main activity or anything that extends the Activity class can be considered a controller as it serves as an interface for human input and relays that information to the Model. Lastly, the Model, is a class or multiple classes we can create in order to full capture the logic and simulation of interface.

2. Multithreading in Android is very similar to the that of Swing. At it's base we're creating different Thread Classes and for each of those Thread classes we can create a custom class that will implement the interface Runnable. In addition we can call many similar functions like sleep and wake, etc.


Claire Tuna - 3/6/2013 13:34:31

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?

The Android SDK sort of follows the MVC paradigm, but not concisely. The XML layout files are the view. The Java files act as the model and controller. They serve as the model because they store the data of the application in variables that have state. Because we haven’t learned how Android works with databases/persistent data, I don’t feel extremely confident saying that the model code lives only in the Java files. I’ll have to see. The Java files also include the controller, that is, the link between the data and the view. In the Java, one can change a view’s content through methods such as setText() and setContentView(). However, Android presents a two-fold mechanism for creating views. One could create the views entirely in the Java files, because each XML view has a corresponding java method. Because of this, the Android system is not entirely modular. Some view code may be in the XML, whereas other view code is found in the Java.


2. The Goetz et al reading describes threading issues for Java Swing, a GUI SDK that many Java desktop applications use. The Android SDK also uses a single GUI thread. 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?

I was unsure of how to answer about Android based on only the reading, so I also read the “Processes and Threads” android developer guide. Android also has a main thread of execution, which is the only thread that should access the UI directly. In Android, the programmer has two options for long-running tasks: dispatching a worker thread or using AsyncTask. For example, if a button caused a long-running task to occur, in the button’s onclick method, the programmer would create a new thread that ran the process and start that thread. If this worker task needs to access the UI after it completes its long-running task, it can call the UI through methods like Activity.runOnUiThread(Runnable), and View.post(Runnable), so that the interaction is threadsafe. Another option is the AsyncTask, which does the same thing as the worker thread, but in a more strictly organized way. In the AsyncTask class, there is a method called doInBackground(), in which the programmer place the background task, and a method called onPostExecute(), which is called by the UI after the task is completed, so the programmer no longer needs to worry about passing threads to the UI. The SwingWorker framework is similar to the Android worker thread framework. However, it additionally includes cancellation, completeness notification, and progress indication. This is helpful so that the GUI can updated itself to display the progress of a thread. I am sure that this could be implemented in Android as well, but the documentation didn’t mention an explicit framework. If the programmer were using AsyncTask, there would not be a clear way to dynamically send a measure of progress back to the GUI, because “onPostExecute()”, which contacts the UI, is only called after the background task has completed. However, in AsyncTask, there is a clear way to signal completion to the GUI, because that could happen in onPostExecute. I think that the programmer would need to use a custom worker thread in Android in order to switch back and forth between doing the background task and contacting the GUI to give it progress updates.


kayvan najafzadeh - 3/6/2013 13:36:03

1. Yes, the model class in android could be the the res folder or very specifically the Values folder and its containing XML files. Because these objects have to-one and to-many relationships with other model objects (line values stored in String.xml), encapsulate the data specific to an application and define the logic (like the layout files), and much of the data that is part of the persistent state of the application (whether that persistent state is stored in files or databases) should reside in the model objects after the data is loaded into the application (like all the res files). The view objects are "Views" in android. They draw themselves and they can use models. And as controllers, Android has listener classes for each view which can react to the events and in respond change the data or the view.


Minhaj Khan - 3/6/2013 13:36:38

Android in a sense does follow the MVC paradigm. The Views are XML files which dictate what the screen will look like. The Controllers are the Activities which take user input and events and connect the Views and Models. The Models can be implemented by building multiple classes that are separate from Activities which the Activity controllers can use in their processing.

Android SDK achieves thread safety via thread confinement: all GUI objects, including visual components and data models, are accessed exclusively from the event thread.additionally, since there is only a single thread, GUI tasks are processed sequentially, one after the other. For long running tasks, such as spell check, the tasks may be offloaded to another thread which is called by the GUI thread. Special care must be taken to coordinate the response of the second thread with the processing in the original GUI thread. These methods for handling GUIs in Android SDK are similar to Swing methods.


Avneesh Kohli - 3/6/2013 13:43:56

Yes, the Android SDK does follow the Model-View-Controller paradigm in a way. The XML files where we can drag and drop (or manually code) UI components would represent the View. The controller is directly mirrored by Activities in Android, which essentially control what is displayed in the View. There isn't a specific class or format for the Model like there is in a framework like Ruby on Rails, but the developer can create any number of object classes to represent them and do computational operations on state.

The Android SDK uses processes to host an Activity and it's associated UI services, while pushing other computational processes to the background. This allows for the Activity who's view is present to take over the UI thread and accept touch events, then send them to the backend process to be computed.


Kimberly White - 3/6/2013 13:50:27

1. Yes, the SDK follows the Model-View-Controller paradigm. The view is generally done through XML in the layout. The controller is the java code, which connects onClick or listeners to methods. The model, if it's complex enough, should logically be separated into its own classes and methods. While there are no physical bounds in place to keep a programmer from mixing the controller and the model together, the SDK is set up to allow for an MVC-style implementation.

2. The classes for dealing with threads appear to be ASyncTask, Thread, and HandlerThread. The implementation seems similar to that of Swing.


Jian-Yang Liu - 3/6/2013 13:51:36

1) To some degrees, the Android SDK follows the Model-View-Controller paradigm. The main class is usually the View (especially if it extends the View class), while models usually refer to the private classes we've written so that we can better manipulate objects (as in the paint program when we created new paths). The controller is easily the action listener objects/methods, rather than classes, since they'll respond to user actions by affecting the models.

2) In Android, the system guards against applications that are insufficiently responsive for a period of time by displaying a dialog that offers the user an option to quit the app. However, there are methods and mechanisms that help developers avoid this dialog. It, similar to the Swing mechanism, allows the developer to not perform work in the UI thread, but instead create a worker thread and do most of the work there. This keeps the UI thread, which drives the user interface event loop, running. The most effective way to create a worker thread is to extend AsyncTask and implement doInBackground() method to perform work. One can call publishProgress() on the thread to post progress changes to the user. One can also create his/her own thread, but the developer must set the thread priority to a lower one; else, the thread will operate on the same priority as the UI thread by default. Then, the developer can make sure that the UI thread doesn't block while waiting for the worker thread to complete by providing a Handler for the other threads to post back to upon completion. From all this, then, we can see that the Android SDK functions and methods are quite similar to the Swing mechanisms.


Sangyoon Park - 3/6/2013 13:54:42

1. The Android SDK has implemented MVC architecture. For the view, when we are making an app, we use XML files to place texts, buttons, and more objects on the screen and even to save global strings. For the controller, all kinds of event handlers are one good example of controllers. They explicitly deal with communications from users so the input from a user would be translated and passed to the model. And for the last, data structures and associated classes to manage the data can be represented as model. 2. For Android SDK, since the main thread is the only UI thread, it should not be blocked to wait some tasks are done. For example, let's say a database query is done in UI thread, then the UI thread should wait until the result of the query is passed to the thread. During that time, all the other user inputs must wait or must be not responsive. To prevent that kind of traffic, all work should be done in worker thread, and Android SDK supports functions such as, Activity.runOnUiThread(), view.post(), view.postDelayed(). Those functions make worker threads gain access UI thread, so worker threads usually do the hard works (since those are many and not sequentially running), and they can call UI thread only when they need.


Monica To - 3/6/2013 13:58:40

1). Yes, I believe that the Android SDK follows the Model Veiw Controller paradigm. It seems that MVC is already somewhat implemented because the MVC pattern has the model which tells it what to render, the view tells it how to render it, and the controller is user input and triggered events. In Android, the developer defines the UI in XML files and defines resources in XML files by locale. Then the developer extends classes and make use of the XML files by inflaters. In addition a developer could make many classes for the model.

2). The Goetz et al reading mentions the prevalence of the single GUI threading systems that many GUI toolkits use. This system essentially has a single main event thread that processes all tasks for the UI. This is problematic because long-running tasks may cause poor response times for shorter threads waiting to run and users will most likely get really frustrated for these long stalls. The solution is to have background threads run the long-running threads and keep the event thread for short tasks. In Android, also a single-threaded subsystem, there are several ways to tackle handling long-running executions. One way to accomplish this in Android is to use the class Thread, Handlers, and Runnable. In Swing, there are also threads and thread functions used. The Android Thread class has functions like interrupt(), join(), start(), stop(), yield() and etc. that could help the developer create background threads to run backgound tasks.Another possible method to have heavy tasks run in the background is to use AsyncTask. AsyncTask is a class that enables proper and simple use of the event thread. It will allow the user to perform long-running operations in the background and publish results to the main thread without the stress of managing threads or handlers. AsyncTask has protected methods like doInBackground() that essentially performs a computation on a background thread and similar to Swing, it has onCancelled(), onPostExecute() to run the event thread after a doInBackground() has been called. The methods to achieve a single GUI threading system in Android ultimately result in being very similar to that in Swing, but there are multiple ways to accomplish this and the submethods are a bit different but ultimately accomplish the same thing. In Android, also a single-threaded subsystem, there are several ways to tackle handling long-running executions. One way to accomplish this in Android is to use the class Thread, Handlers, and Runnable.


Brett Johnson - 3/6/2013 13:59:25

1) Android can follow the MVC programming paradigm if the application developer chooses to to do so. The XML file that the developer specifies acts as the view, while Android activities can be seen as the controller. The model can be any resource file or any class that the developer creates or extends to hold data.

2) Android gives a couple of options for multithreading. Tasks that will take a long time can be run in a background service, or the work can be done in a backgroud thread (http://grail.cba.csuohio.edu/~matos/notes/cis-493/lecture-notes/Android-Chapter13-MultiThreading.pdf). Similar to the Swing SwingWorker class showed in the reading, a non-UI thread in Android can pass information to the UI-thread about progress in order for it to display to the user. Android protects against some programming mistakes. For example, it will not allow the programmer to update UI elements from a non-UI thread. As another example form the android developers blog, “the AndroidHttpClient does not allow itself to be started from the main thread” because this would be far too slow. (http://android-developers.blogspot.com/2010/07/multithreading-for-performance.html)


Oulun Zhao - 3/6/2013 14:05:44

1. Yes Android SDK follows the Model-View-Controller model, The layouts, also images or other raw data files are the views, they will determine what the views look like. The activities are the controllers, doing the logics behind user events. When an event is triggered, the activity collects information from the models and builds the view. Models normally are implemented as classes from my experience with cs169. Therefore, in Android SDK, the user can build their own classes to implement models.

2. In Android, handlers act like a middleman between a new thread and the message queue. It could either run the new thread and use the handler to post a runnable which updates the GUI or run the new thread and use the handler to to send messages for UI changes. They are similar to the Swing mechanisms.


Harry Zhu - 3/6/2013 14:06:12

The Android SDK loosely follows the MVC paradigm. The views are implemented in the xml layout files, and the controllers and models are implemented in the activities. The controllers are the listeners, while the models are the various functions in the activities.


André Crabb - 3/6/2013 14:08:41

1) The Android SDK doesn't directly follow the MVC paradigm. When you create a new project in Xcode, it creates the files <ClassName>ViewController.h/m. Although its still up to the developer to implement properly, Apple is at least helping you develop your app in according to the MVC paradigm. Android doesn't do this for you, and its completely up to the developer to implement their app according to the MVC paradigm. Although this is doable, it may not be as easy as it is in Xcode/Objective-C. The way Android differs is by having the basics of the view defined in various XML files. However, there is no specific file that is supposed to interact with these XML files, unlike Cocoa development where a ViewController file is associated with every "*.nib" file.

2) The tools available to Android developers that assist with long-running exectutions are essentially the same as the Swing tools. This is because Android is written on Java, and thus has the entire API available to it. The Exectuor class that's talked about in the reading is in the Java package "java.util.concurrent" which an Android developer could include in his or her program. That being said, the tools available are these Executor objects, Thread objects, ThreadPools, and basically anything else the developer defines as a Runnable.


Timothy Wu - 3/6/2013 14:09:29

1. The Android SDK does not completely follow the Model-View-Controller paradigm, but it has aspects that roughly correspond to each of the three parts. For the Model, users can create any number of separate classes that handle interaction between data stores. For Views, Android has the XML layouts that define the GUI's appearance. And lastly, for the Controller, Android developers make subclasses of class Activity that define the behavior of individual screens of the application. Examples of behavior defined in Activities include event handlers for click events, life-cycle events, and various touch gesture events among others.

However, the Android SDK is different from the MVC paradigm in that the Activities, which represent the Controller, and the Views, which are represented by XML layouts, are not decoupled as in traditional MVC. In Android, the Views and the Controllers cannot exist without each other and are strongly linked together, stripping away the philosophy of modularity between the different pieces of MVC. Activities must have a corresponding XML layout, and for an XML layout to be in use, it must have a corresponding Activity that invokes it. This strong coupling between Views and Controllers makes the Android SDK notably different from the MVC paradigm.


2. In order to handle long-running executions, the Android Developer Guide recommends to, "use the various APIs provided by the java.util.concurrent package, such as Executor, ThreadPoolExecutor, and FutureTask." For the Executor class, it attempts to decouple task submission from mechanics of how each task will be run. It gives you the freedom to either execute a task immediately in the calling thread, or to create a new thread that will then execute the task. The ThreadPoolExecutor is a class that manages a large thread pool, which helps with executing a large number of asynchronous tasks, as well as bounding and managing resources. The FutureTask class has methods to start and cancel a computation, query to see if computations are complete, and retrieve results of computations.

All of these functionalities are quite similar to the Swing mechanisms, especially Executor and FutureTask. Swing also has classes of similar names like AbstractExecutorService and FutureTask, and they provide similar functionality, like creating new threads to execute tasks, and to give options to cancel or track progress of threads. For ThreadPoolExecutor, the Swing analogue would be the ThreadFactory, which also does the task of bounding and managing resources. Overall, Android and Swing have fairly similar mechanisms for managing threads.


Soyeon Kim (Summer) - 3/6/2013 14:11:07

1. Android SDK follws the Model-View-Controller paradigm but it is mostly tied to “View” part. Activity corresponds to controller, model corresponds to subclass of application, and view correctness to anything that subclasses View.

2. Mechanisms such as binding a long-running task to a visual component or binding or “thread hopping” through supporting long-running task with user feedback allows developers to handling long-running tasks in GUI applications. Also, helper classes like the BackgroundTask class are built for cancellation, progress indication, and completion indication.

 The Swing mechanism is slightly varied but mostly similar; for cancellation, progress indication, and completion indication in Swing, these features are developed and provided by the SwingWorker class. SwingWorker is a framework that uses FutureTask and Executor to execute long running tasks in background threads. In Swing, helping GUI tasks execute code in other threads is not provided, however, creating their own Executor for processing long-running tasks solves the problem. 


Achal Dave - 3/6/2013 14:16:23

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?

To an extent, Android does follow the MVC principles: The XML files define the view, which has very little logic in it (except the occasional onClick attributes and such); the Activity files can be considered a controller that handles events from the view and communicates with some Model (though there isn't a specific separate idea of a model--it would generally be a database or perhaps a separate set of Java classes). However, when we examine it further, the model does break down. Controllers are tied to their views in the sense that Activities generally correspond to one layout and layouts can't be instantiated without a corresponding activity. As mentioned earlier, there isn't exactly a specific separation for a "model", either.

Overall, while Android has some MVC principles, it's not strictly an MVC system (in fact, the docs never really mention MVC, either).

2. The Goetz et al reading describes threading issues for Java Swing, a GUI SDK that many Java desktop applications use. The Android SDK also uses a single GUI thread. 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?

So far, we have not covered Android threading mechanisms much, so my response is from searching around and reading about it. One of the primary ways of scheduling background tasks in the Android SDK is to use an AsyncTask, which has some tasks that it needs to run in the background. Once these tasks are completed, it calls a callback function provided to it on instantiation.

Swing, on the other hand, asks developers to handle threads more directly. You ask for a thread from a thread pool directly, and handle what happens when the task ends yourself. Android, on the other hand, with AsyncTask will handle threading for you--you don't really deal with raw threads, but rather generally say "do this in the background, then call this function", and Android takes care of finding a thread and running the process on it.


Derek Lau - 3/6/2013 14:19:05

Android has classes for the form in the Model of Cursors, which help to navigate SQLite databases. However, in Android, the View and Controller are very tightly coupled in the form of an Activity. XML files serve to inflate the layout, but in the Activity, which listens to and handles user input events, as well as execute the logic that receives these events, there also resides code to manipulate the display, layout, and views that the user sees. Therefore, since the code that displays elements to the user (View) and the code that handles user input and processes it through the app's logic (Controller) are inseparable by default through the form of Android's Activity, the Android SDK does not by default follow the MVC Paradigm.

Android SDK includes background services (which is a process that runs in the background and is invisible to the user), worker threads (that are native in Java), the following methods: Activity.runOnUiThread(Runnable), View.post(Runnable), and View.postDelayed(Runnable, long) (all three of these methods help access the UI thread from a separate worker thread to avoid undefined behavior), AsyncTasks (which helps handle Threads and Handlers), and IBinders (which help achieve thread-safety when methods are called from multiple threads and processes). Swing mechanisms are similar, as indicated in listings 9.4 and 9.5 under section 9.3, which run and associate new threads with background execution tasks (like using worker threads) and section 9.3.3, which highlights the use of a SwingWorker, which operates much like an AsyncTask in the way that it abstracts the detailed thread handling to a Swing-defined object.


Zach Burggraf - 3/6/2013 14:19:08

1) Roughly speaking, the MVC paradigm is present in Android. The Controller is comprised of all user input functions (events and listeners such as onTouch). The Model is unique to every application and is created by the programmer through custom classes. And the views are the user interface XML and corresponding java to manipulate the activity views.

2) Android uses Activities and Listeners to allow for long-running executions. Swing seems to be different but I am not sure I understand both platforms in enough depth to fully contrast them. One difference is it seems that Swing has a notion of "cancelling" which I have not come across in Android's platform.


Arvind Ramesh - 3/6/2013 14:19:54

1. The Android SDK follows the Model-View-Controller paradigm very closely. The view objects are the xml files that are required for each screen, and all the devices these xml files contain (radio buttons, onTouchListeners, sliders, text input fields, etc.) They are the part of the application the user interacts with. The model objects are the actual classes that contain the java code of the application. For example, in the TipCalculator app, a model object would be the class that takes the inputs and computes the tip. While the user never "sees" model objects, the application cannot run without them. The controller objects are implemented in Android via Intents. The intents can convey information between the xml files and the classes, the exact definition of a controller object.

2. The main tool that help Android developers with long-running executions and background threads is the Service class. This allows the programmar to send long tasks to the background while still keeping the UI active. The user can switch applications and the Service will continue performing is task until it is done. However, the programmar has to specifically tell the Service to spawn a different thread than the main program if the Service is doing CPU intensive tasks.



Arvind Ramesh - 3/6/2013 14:20:02

1. The Android SDK follows the Model-View-Controller paradigm very closely. The view objects are the xml files that are required for each screen, and all the devices these xml files contain (radio buttons, onTouchListeners, sliders, text input fields, etc.) They are the part of the application the user interacts with. The model objects are the actual classes that contain the java code of the application. For example, in the TipCalculator app, a model object would be the class that takes the inputs and computes the tip. While the user never "sees" model objects, the application cannot run without them. The controller objects are implemented in Android via Intents. The intents can convey information between the xml files and the classes, the exact definition of a controller object.

2. The main tool that help Android developers with long-running executions and background threads is the Service class. This allows the programmar to send long tasks to the background while still keeping the UI active. The user can switch applications and the Service will continue performing is task until it is done. However, the programmar has to specifically tell the Service to spawn a different thread than the main program if the Service is doing CPU intensive tasks.



Lemuel Daniel Wu - 3/6/2013 14:26:08

1. The Android SDK doesn't automatically follow the Model-View-Controller paradigm. Instead, it provides UI classes like SeekBars that are view objects, but also store a certain amount of information. And as these things change, they fire ActionEvents. Then, in our your code, there are listeners to their changes which will update your own personally written classes which, in effect, become something like a model. Then, these classes may update other UI view objects in turn, as a controller. This could be seen in the example of a tip calculator that changes the TextView that displays how much a person must pay below a SeekBar as the value of the SeekBar is changed. As the SeekBar (part of the view) changes, the inner classes (like the TipCalculator class) and their variables are changed. After that, the TextView's text is changed to match the new variables' values.

2. Android contains Thread objects that can hold Runnables that can be used to run things in the background. SwingWorkers can also be used to run long-running tasks. These also allow for cancelling and interrupting of tasks before they are done running. This is quite similar to the Java Swing mechanisms, because background executions do not disrupt the GUI thread in both Android and Swing. Similarly, there is only one thread in Android and Swing for GUI work.


Eric Xiao - 3/6/2013 14:27:11

1) Models, views and controllers are very similar to the way Django functions, with models being the object data stored in the database, views pushing data to the templates, and controllers acting like forms would in web development.

Android SDK follows it to a certain degree. The XML is the template that describes the layouts like templates, which are pushed data by the views (Activities). The Models are the resources that are edited by entering data into the forms. These forms are also in the XML, which push data back to the resources.

2) Event Listeners can only take one action in at a time, and each of these go through the execution loop, from taking the event off the queue to calling the right method in the Activity (callback), to making changes in the application. There are also events in the View that are called when something is completed (e.g. OnComplete). These mechanisms all operate on signals to indicate when to start tasks sequentially. Java Swing and the Android SDK both follow this event dispatch loop framework, so they are pretty similar in this regard.


Edward Shi - 3/6/2013 14:28:30

1) Yes, the Android SDK, in a way follows the Model-View-Controller paradigm. The controller would be the touch screen and our touch. This is the user input and how user action can be communicated to the the device. The view object would be the interface on the screen and all the graphics. The controller (our touch) would tap whatever view object we see. The model objects are multiple things in the android SDK. It depends on what we want such as contacts in an address book or it could be information in an application. This all depends on the person coding and specific applications.

2) The Android SDK has Views, onTouch for buttons, and different activities. When you touch a button, you can start another activity. This on touch button or on touch listener is similar to the action listener in swing. Furthermore, Android SDK also has array list which you can save these objects into array (Such as for paints) that allow persistency of those objects. In each Android activity, you can still cause it to go back to another activity. This is similar to the substask runnables in Swing.


Brian Wong - 3/6/2013 14:28:44

1. Android somewhat follows the MVC paradigm, but doesn't always keep elements decoupled as with other frameworks. The closest way to model MVC is to have XML layouts as the view, Activity classes as the model (the logic), and the defined resources (such as @thisbutton) as the controller.

Android has processes and events to keep track of most threading related issues. There are processes such as foreground and background that can be associated with activities, which allows the OS to smartly handle resource allocation. Events are the main way of passing off foreground process to another activity. Intents are created in one activity and passed into another activity as it starts. This is a little different from the Swing mechanisms that are forced to be "in-sync" only because they run in one thread, and cannot rely on the OS to handle underneath an abstraction layer such as a process.


Ben Dong - 3/6/2013 14:29:00

Android does follow the model view controller paradigm. The user interface and resources are defined in various xml files. You can extend activity classes and inflate those xml files to render views. Finally, many utils have already been written, such as DatabaseUtils, etc.

For background tasks, Android uses ASyncTask. This is similar to Java Swing's SwingWorker. Android can also start services to run for a long time in the background, which is similar to Java Swing.


Alexander Javad - 3/6/2013 14:29:38

1) The Android SDK does indeed follow the model view controller paradigm. You can tweak the view in the graphical layout creator. The controller is your Java code you use to implement your methods. The model will be another section in the SDK which makes data requests to the backend servers and passes that data to the controller for processing.

2)


Alysha Jivani - 3/6/2013 14:30:44

(1) The Android SDK does follow the Model-View-Controller paradigm. The model could essentially be any sort of data structure that the program uses to run, like an array, a linked list, variables, etc. This is how the app stores its internal state (the “model”) and the implementation details are abstracted away for the user. The user sees changes made to the model (internal structure) as the view is updated. For Android, View Objects can be things like widgets (e.g. checked radio buttons, a slider, etc.), the View class, or a Canvas. Basically the view is what the user sees and interacts with. Controller objects are event-listeners and the methods that they trigger. They capture the user’s input and then the methods translate it and modify the model accordingly. I think Intent objects would also fall under the “controller object” category because they are used to pass information between events, etc.

(2) In Android, the default setting is that all the components of a single application run in a single process, but a developer can specify a process attribute (in the manifest) so that a component can run its own process. A developer can also declare a new Thread for operations that take longer to run. Also, there is a class called AsyncTask that allows the developer to deal with background threads and it has a method doInBackground() that allows executes the process in a separate thread.


Anh Mai - 3/6/2013 14:31:28

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?

The topic of whether Android follows the MVC model has been one full of debates amongst the hardcore programmers. I feel, personally, that Android does follow the MVC architecture: the model is the classes and methods you define in the background, the views are described in their XML files, and the controllers are user events on the app. Many have argued that user events link together the view and the controllers (which a strict MVC model should not do). Google themselves have not made official claims that Android follows the MVC model.

2. The Goetz et al reading describes threading issues for Java Swing, a GUI SDK that many Java desktop applications use. The Android SDK also uses a single GUI thread. 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?

Android and Swing are very similar in their threading issues and properties. Android's AsyncTask is the same as Java Swing's SwingWorker method. However, Android does offer more control because it offers a specific method called runOnUiThread() that allows you to forcefully run a task on the UI thread.