In the past I posted a link to the Oracle ADF Faces Rich Client demos (server-based web applications). Now that the Oracle ADF Mobile framework for native iOS and Android applications has been released, a similar demo is now available: the Oracle ADF Mobile mock component gallery.
This mock component gallery is based on the real component gallery application bundled with the ADF Mobile JDeveloper extension. The recommended best place to view this demo is using the mobile Safari or Chrome browsers on your iOS and Android devices. Doing that will give you the closest experience to how the components will appear and behave in real ADF Mobile applications. However, you can also view the demo using desktop Safari and Chrome for an approximate experience when access to a mobile device is not available.
If you are noticing client-side performance issues in your ADF Faces application and must support legacy browsers like Internet Explorer 7 and Internet Explorer 8, there are many techniques available to help optimize your application for these browsers:
- If you use af:region and the jsff page fragment files have more than 1 root component, optimize it by arranging these components with a single root component. For example, if you want your region contents to stretch, you might have one visible content component and a series of popup components, put the visible content component inside of a “center” facet of an af:panelStretchLayout and put all of those popups in the “bottom” facet but also make sure to assign bottomHeight=”0px”. If you don’t want the contents to stretch, simply wrap these components with an af:panelGroupLayout layout=”vertical”.
- Avoid using a af:panelStretchLayout where topHeight, bottomHeight, startWidth, or endWidth is set to “auto”.
- Minimize uses of af:panelAccordion in discloseMany=”true” mode if possible.
- Minimize use of components that provide overflow popups, e.g. af:panelAccordion, af:panelTabbed, af:toolbar, af:breadCrumbs, af:menuBar. If you have to use these components, make sure that your target screen size can accommodate the content without having to invoke overflow.
- Minimize use of components that provide custom title text truncation, e.g. af:panelHeader and af:showDetailHeader. If you have to use these components, make sure that your target screen size can accommodate the title text without having to truncate.
- Minimize use of af:carousel, af:table, af:tree, af:treeTable.
- Avoid complex user interfaces. Users will struggle to process complex application structures. Legacy browsers will struggle with processing of complex content. Keep the number of tabs simple (use less than 10). Keep the number of columns in a table small (use less than 10).
- Finally, don’t ignore the warnings that JDeveloper gives you.
As browsers evolve, changes have been made with how the HTML “accessKey” attribute works. There are differences across platforms for the same browser version as well as differences across browser versions on the same platform. There are even some cases where the exact same browser treats accessKey differently for button elements vs. anchor elements! This post shows some examples of how to invoke the accessKey and what the behavior is.
Sample button and anchor HTML using the “accessKey” attribute
How different browsers handle the above accessKey letters for button and anchor elements
|Browser||Operating System||Key Combination||Button Behavior||Anchor Behavior|
|Chrome 7.0.517.41||Linux||Alt + letter||Clicks the button (3)||Clicks the anchor (3)|
|Chrome 7.0.517.41||Mac OS X||Control + Option + letter||Clicks the button (3)||Clicks the anchor (3)|
|Chrome 7.0.517.41||Windows||Alt + letter||Clicks the button (3)||Clicks the anchor (3)|
|Firefox 1.5||Windows||Alt + letter||Clicks the button (1)||Unknown|
|Firefox 2||Linux||Alt + Shift + letter||Clicks the button (1)||Clicks the anchor|
|Firefox 2||Mac OS X||Control + letter||Clicks the button (1)||Clicks the anchor|
|Firefox 2||Windows||Alt + Shift + letter||Clicks the button (1)||Unknown|
|Firefox 3||Linux||Alt + Shift + letter||Clicks the button (1)||Clicks the anchor|
|Firefox 3||Mac OS X||Control + letter||Clicks the button (1)||Clicks the anchor|
|Firefox 3||Windows||Alt + Shift + letter||Clicks the button (1)||Clicks the anchor|
|Internet Explorer 6||Windows||Alt + letter||Sets focus on the button (2)||Unknown|
|Internet Explorer 7||Windows||Alt + letter||Sets focus on the button (2)||Sets focus on the anchor (2)|
|Internet Explorer 8||Windows||Alt + letter||Clicks the button (3)||Sets focus on the anchor (2)|
|Internet Explorer 9 (beta)||Windows||Alt + letter||Clicks the button (3)||Sets focus on the anchor (2)|
|Safari 3.1.2||Mac OS X||Control + Option + letter||Clicks the button (3)||Clicks the anchor (3)|
|Safari 3.1.2||Windows||Alt + letter||Clicks the button (3)||Clicks the anchor (3)|
|Safari 5.0.2||Mac OS X||Control + Option + letter||Clicks the button (3)||Clicks the anchor (3)|
|Safari 5.0.2||Windows||Alt + letter||Clicks the button (3)||Clicks the anchor (3)|
- Red = Different behavior for buttons and anchors
- Comment 1 = To just set focus on the button/anchor, change your about:config setting for the “accessibility.accesskeycausesactivation” user preference.
- Comment 2 = Press Enter to click the button/anchor
- Comment 3 = There appears to be no built-in mechanism to just set focus on the button/anchor. The component handling the click event would be responsible for setting focus while handling the click.
It is becoming an epidemic. More banks and employers are making changes to their web applications that they think are protecting both your and their interests but in practice, this is actually doing quite the opposite.
If your bank or employer is a well-known business, it is likely a frequent target for phishing attacks. More people are relying on Google searches and other websites that generate “tiny” URLs (long URLs are redirected through a third party with a short URL that can easily be typed in a chat client, email, etc.). This means that people aren’t using bookmarks to access their banks or companies which means if a website looks familiar to you, you aren’t going to pay close attention to the URL in your browser’s address bar. On the same token, it is easy for fat fingers to slightly mistype a URL that you know by heart so you can easily go to a website different than what you intended and will fall victim to a phishing attack. More and more banks and employers are becoming paperless so any interaction that is requested of the user comes from email. An email has many ways to fool the user into believing that it and the links provided in the email are authentic.
How are my banks and my employer putting my security (and theirs) at risk?
The reason is that they are implementing various mechanisms to prevent your browser from saving and recalling stored user names and passwords. This can be achieved by either adding autocomplete=”off” to the input fields or to the form that wraps these inputs. Another mechanism that is becoming more prevalent is the technique of asking for your user name in one screen and then your password in a second screen after the first screen is submitted. These mechanisms break the password storage and retrieval features of your browser.
Why does denying password saving put us at risk?
There are two reasons why this is very bad. Both reasons come from human error:
- Requiring that a human type in the user name and password means that the human must concentrate on typing in the data rather than analyzing whether the website is authentic. If the browser populated the user name and password fields, you know immediately that the website is the correct one. If the fields are blank and the user knows that the password should have been recalled by the browser’s saved password mechanism, the user becomes surprised and starts to question if they are visiting the correct page. If the browser never saves the password, the user no longer has a fast and accurate way to know that the website is authentic.
- Requiring that a human type in the user name and password encourages the user to have a password that is as easily memorized and typed as possible. This makes it an easier password to guess; fewer iterations to attempt before success. It may also force the user into reusing the same password for every website. Reusing passwords is bad because if one website is compromised, all other websites are wide open. If the user is conscientious about using unique passwords, they are then forced to write down the passwords and post them in an easily-accessible but also vulnerable location in their cubicle at work or desk at home where everyone in your office or everyone who visits or breaks into your home can access it.