Sample Question:

sdfsdfsf

From Sample Paper 1 - 2014:

Continued from the first part of question # 13.

(The sample paper, so the marking scheme can be shown.)

 

JSR Notes:

There are two main take-away points from this assessment statement:

1. One is the realization that applications made for a certain operating system (like for Mac OS) do indeed look, and feel, and operate in similar ways. Mac applications look more like Mac applications, and Windows applications look more like Windows applications.

2. But equally important is this point, from the Teaching Note:

Students should understand that some features are provided by the application software and some by the operating system.

If something looks similar between various applications, such as the shape of a window and its red, yellow and green buttons in the corner, or the way menus work, that feature is probably coming from the OS. Though, not necessarily.

GUI as the Most Obvious Common Feature

- A GUI (Graphical User Interface) system of interaction is the most obvious feature common to applications. The GUI allows users to interact in a natural and intuitive way, using a mouse and the keyboard, and various graphical components, such as OK buttons and menus. Other common GUI components include: drop-down menus, radio buttons, sliders, etc. Many applications share these features. The GUI components that Java uses are called Swing components (they include things like like JTextFields and JButtons).

Note that part of the functionality of these graphical features can come from Java, and part from the OS.

Core (GUI) features likely come from the OS. For example, the actual final look (rounded button corner, for example, in the Mac OS) come from the operating system. And also, other core functionality, like the way menus and menu items work.

But other, more specialized (GUI) functionality may come from the application/Java - for example, the way a slider or JTable works.

Non-GUI Common Features

There are many other features common to most applications (see the list below). Most of these can be fully or partially provided via the OS, but some of the below list could be customized or modified by a certain application, or indeed be controlled entirely by the application itself. Modification of some will not be allowed by the operating system, for one reason or another, including the desire that all applications using that particular feature have it work in an exactly consistent way. A GUI example of that situation might be the red, amber, and green buttons of all Mac application windows.

List of Common Features of Applications

So here is a list of things which often work the same way between various applications (and so likely are indeed coming primarily from the OS, though not necessarily so)

• copying & pasting, and deletion
• importing (images, etc), and format conversions required for this
• exporting - to various formats
• saving & opening, and duplicating
• file management
• windows, and scrolling within them, and resizing
• dragging, and re-arranging of GUI components in various layouts (which can be user defined and saved)
• user motions, multi-touch, gestures, etc.
• zooming
• accessibility features for people with disabilities
• security
• bolding and other text manipulation features
• multiple files able to be worked with at the same time
• resizing,
• and so on - think in term of the programming that would be require to do some of the above

So again, remember that all these features may be fully or partially provided by the operating system, or entirely controlled by the application itself. Ask yourself which of list above are most like entirely controlled and provided by the OS, and which are one less likely to be.

 

Who's in Control, the Application or the OS?

A lot of times it's hard to tell for sure "who's in control", the application, or the OS. But if we go back to GUI components, this can be an easy category of things to make a really good guess. Some of the key features of GUI elements appear differently in Windows and Mac versions of the same Java program, so it must be the OS in control (remember, the same Java program can run on multiple operating systems.)

Take, for example, the rounded corners of Mac OS buttons, along with their particular shades of grey that they are - these are specific for Mac OS or Windows, so for sure they must come from the operating system (even though their functionality, when they are clicked, likely comes from the Java application.)

And, for us, working with Swing GUI components in Netbeans, we don't even have to run an application in two operating systems to know it's the OS in control of a certain feature. Take a look, for example, at the three "stop light" red, amber, and green little circles at the top left hand corner of all windows. When you look in the Netbeans GUI Design editor, you don't even see them at all, but when you run the program on a Mac, you do (see below). So OS or Java? The answer is clearly OS.

         

Here's another example of one of many user preferences that clearly the OS is in control of. You can make it so that the scrollbar of windows (of all applications) always shows. In this case, we know it's the OS in control, as the setting is changed in the General System Preferences of the Mac OS, yet it is applied to all applications.

In terms of when the application itself is "in control", we need only think of features that are very specific to certain applications. Here are some examples:

IntelliJ IDE (which we use for programming)

• compiling code
• debugging the code

Photoshop

• all the filters, like blur and fish eye
• adjusting the relative colors/hues

iMovie

• transitions
• title effects

 

Applications Themselves Providing Common Features

Common features do not necessarily have to come from shared resources via the OS.

Helping maintain consistency are the applications themselves, is adherence to programming frameworks, and published style guides. Most programmers of applications do their best to adhere to such conventions, which their users have come to expect.

And in fact, it doesn't matter so much if they come from the OS itself, or from applications adhering to conventions, both the OS and applications themselves help provide consistent, common features.

 

Advantages of Common Features

Usability & Increased Comfort

Consistent look and feel and operation, which helps people switch between & learn various applications, and yet have a good idea how to use them.

Better Accessibility

And as noted in the S/E Teaching Note above, this is particularly beneficial for persons that have difficulty using computers in the first place, whether it be because of disability, age, or lack of experience.

Easier Development

Software developers can just take advantage of libraries/modules of common features. It would be too much work, and in fact a waste, to "re-invent the wheel". Why should every new application have to code how to do drop down menus and so on, for example?

 

---------------------

Finally, in terms of accessibility, even without the real thing, kids with a lack of experience... indeed a lack of computers... can get use to and comfortable with a certain kind of environment, like that of Microsoft Word. Check out this resourceful teacher in Ghana:

 

 

--------------------------

--- EXTRA - NOT NEEDED AS PART OF THIS ASSESSMENT STATEMENT, BUT TAKE A LOOK IF YOU LIKE. ---

 

 

Shared Libraries and Potential Pitfalls

dll Libraries

Particularly on Windows machines, there are lots of features that can be used from the OS classes. These are typically stored in and accessible from "dll" libraries, which are as their name suggests: dynamically linked libraries; i.e. libraries available from the OS that are available to other applications, dynamically, as they are needed.

Issues With Sharing Resources

But there is one major drawback to the use of dll libraries: corruption of dynamically linked libraries by poorly programmed applications, in which case an application that had no part in the corruption of the dll library experiences problems when trying to use it. (The analogy here you could think of is careless kids taking books home from the public library and ripping the pages, then returning the books to be checked out by careful kids.)

To avoid this problem Unix and Mac computers tend to have all of the functionality of applications kept within those applications, and so no usage of common shared libraries. They thereby do lose the benefits of sharing, but the advantage of this approach is they don't have to worry at all about side effects caused by other applications.

Furthermore, note that a good OOP (Object Oriented Programming) approach, using encapsulation principles, dictates that key functionality of a particular application should be kept within its own classes.