iOS Web Inspector

If you are using iOS 6 and Safari 6, you can inspect web pages shown in Mobile Safari or in WebViews of applications like those created with ADF Mobile. This can either be in the iOS Simulator or on a device (iPhone, iPad, iPod touch) connected over USB.

In Safari 6, enable the “Develop” menu:

From that menu, your connected devices and iOS Simulator will display as submenus. Each submenu will list all of the WebViews that you are able to inspect (if you are not sure which one you want, a highlight will appear on your device or in the simulator as you hover over each menu item):

A web inspector window will open:

In the first column, the panel with a document icon (1) is where you can browse the DOM, look at scripts, style sheets, etc.  When the HTML page is selected, the middle panel will show you the DOM tree (3) which you can manually browse for an element. Alternatively, you can use the hand tool (2) to click on the screen (of the actual device or the simulator) to pick an element that you want to inspect.

With an element selected, you can then use the “{}” icon (4) of the right panel to view the element’s style properties.  This will show you the exact selectors that are providing each style to the element (5). This is incredibly valuable, particularly when multiple selectors are competing (a line will strike out any styles that lose due to some other more specific selector). You can also edit those values directly or add additional properties and see the change immediately take effect on the screen. Unfortunately, there’s no way to save off any changes you’ve made. If you are trying to create a custom style sheet, you’ll need to jot down elsewhere the changes you’ve made; if you leave the page or close the app, you’ll lose your changes.

CSS Shorthand Tokens

In CSS, you will come across some shorthand notation for the margin, border-color, border-style, border-width, and padding properties. It isn’t obvious or easy to remember which token in the value applies to which side of the element so here’s a handy list of the 4 possible varieties:

1. One token — all-sides-use-the-same-value
2. Two tokens — top-and-bottom right-and-left
3. Three tokens — top right-and-left bottom
4. Four tokens — top right bottom left

At least the four-token example can be remembered by associating the element with a clock where time progresses clockwise.

HiDPI Images in ADF Mobile Applications

Whether you are developing an ADF Mobile application or a classic ADF Server application, it is becoming more and more important to support HiDPI screens (high resolution or “retina” displays). There is no easier way to make your application look out-dated than to use grainy, unprofessional image assets or use them improperly.

In HTML, the “px” unit corresponds to the same amount of space regardless of the DPI of your device (however, the number of device pixels may vary). The original iPhone models did not have HiDPI displays. Each point of color on those screens corresponds to one HTML CSS “px” unit. Newer iPhone models introduced a HiDPI (or “retina”) display that has 4 device pixels in the same amount of space that 1 device pixel used to take up (2 device pixels wide by 2 device pixels tall); on these new devices, the width and height “px” values use twice the amount of device pixels.

Why is this a common problem? Since ADF Mobile uses HTML, displaying an image is not as simple as just specifying the source path and magically hoping the browser will know that you are using a high resolution image. You must specify dimensions to go along with the source path.

Let’s work with an example. You have an image named “image-64.png”. This image has a size of 64 by 64 individual dots of color (individual points of color information). If you coded your page like the following, the image will be shown with a width of 64px and a height of 64px (one color dot per “px”):

<amx:image id="i1" source="images/image-64.png"/>

This would look just fine on a classic low-DPI display. However, on a HiDPI display, it still takes up the same space but since there are more device pixels, the image will look very grainy.

In order to look crisp and professional, you need to set a size so that each dot of color corresponds to at least one device pixel. For a HiDPI display, this means your image needs a width and a height specified such that you use 2 dots of image color information per HTML CSS “px” unit (e.g. a 64 by 64 sized image should be specified to use a width of 32px and a height of 32px. In code, your page should look like this:

<amx:image id="i1" inlineStyle="width:32px;height:32px" source="images/image-64.png"/>

Even if you still want to support legacy devices for your application, this same image (with the same specified width and height) will look beautiful on low-DPI screens because of how images are processed modern browsers.

If for some reason you really needed or wanted to specify alternate images for each kind of device, you have the option to use a device properties EL variable to toggle the rendered state of alternate amx:image components or simply use that EL to alter the inlineStyle and the source path as desired.

Browsers and the HTML accessKey

Background

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

<html>
<body>
<button onclick="javascript:alert('hi button with onclick')"
        accessKey="r">Button t<u style="color:red">r</u>y me</button>
<a href="javascript:;" onclick="alert('hi anchor with onclick');return false;"
        accessKey="o">Anchor with <b style="color:red">o</b>nclick</a>
</body>
</html>

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.

One-off ADF component skin appearance

Have you ever wanted to make an ADF Faces Rich Client component have a unique appearance but not change all other instances of that component? You can as long as the things you want to change are not skin properties or skin icons (server-side aspects like properties and icons are not part of the client-side generated style sheet so this client-side solution will not allow you to change them).

Let’s start with an interactive example; the skinning demo pages for the ADF Faces Rich Client:
http://jdevadf.oracle.com/adf-richclient-demo/components/skinningKeys/inputText.jspx

On this page, there is a right-hand side where you can see some example inputText components.  When you click on the checkboxes on the left-hand side of this page, the appearance of those start to change.  However, the inputText for the find field at the top of the page does not change.  This is because of some containment selector definitions in the skin used on this page that confines the custom styling to instances of the inputText that are contained in another component that has a particular style class.  Since the find field is not inside of that container, these custom styles do not apply to that field.

Let’s say your page has a structure like this:

<af:panelGroupLayout id="pgl1" layout="scroll" styleClass="SpecialMarker">
  <af:inputText id="it1" label="Name"/>
</af:panelGroupLayout>

To style that inputText specially in this container, you would create skinning definitions like this:

.SpecialMarker af|inputText {background-color:pink}
.SpecialMarker af|inputText::access-key {color: aqua;}
.SpecialMarker af|inputText::content {background-color:red}
.SpecialMarker af|inputText::label {font-weight: bold}

Alternatively, you could put your marker directly on the inputText like this:

<af:inputText id="it1" label="Name" styleClass="SpecialMarker"/>

and have skinning definitions like this:

af|inputText.SpecialMarker {background-color:pink}
af|inputText.SpecialMarker af|inputText::access-key {color: aqua;}
af|inputText.SpecialMarker af|inputText::content {background-color:red}
af|inputText.SpecialMarker af|inputText::label {font-weight: bold}

Deploying your application to a reserved port number

Ensure that you avoid reserved port numbers when deploying your application. Some application servers will fail to prevent you from deploying your application on a reserved server port (e.g. 1, 7, 9, 11, 13, 15, 17, 19, 20, 21, 22, 23, 25, 37, 42, 43, 53, 77, 79, 87, 95, 101, 102, 103, 104, 109, 110, 111, 113, 115, 117, 119, 123, 135, 139, 143, 179, 389, 465, 512, 513, 514, 515, 526, 530, 531, 532, 540, 556, 563, 587, 601, 636, 993, 995, 2049, 3659, 4045, 6000, 6665, 6666, 6667, 6668, 6669). If you use one of these reserved ports, some web browsers may honor it but at least WebKit-based browsers (e.g. Safari and Google Chrome) will not. You may see some page content but all resources (images and styles) will fail to load.

Custom Java Bind Variable in a Where Clause of an ADF View Object

You can make a JDeveloper model View Object (VO) use a data query that has a custom variable accessor in Java.  This is useful for cases where you want your where clause to select based on the current user name from the ADF Security context.

Go to the “Query” tab of your view object:

Add a new Bind Variable and make sure to specify “Expression” and give the value the Groovy expression “adf.object.viewObject.yourPropertyName”.  The “adf.object.viewObject” portion is essentially like saying “this object” and then it will call getYourPropertyName() to fetch the value:

Back in your query expression, refer to this new bind variable by its name but prepend “:” to indicate that it is a bind variable as shown above.

Select the “Java” tab of your view object and then click the pencil icon to edit the settings:

Select the “Generate View Object Class” and “Include bind variable accessors” options:

This will generate a new “.java” entry under your view object in the JDeveloper application navigator:

Finally, open that Java file and change the implementation of your get accessor as you wish.  In my case, I am simply returning the user name property from the ADF security context.  I also changed my set accessor to do nothing:

Decrypting Margin, Border, and Padding Styles

When working with ADF Faces skins, JSF inlineStyles, or just CSS in general, you may have come across some explicit style definitions like this which is very easy to understand:

padding-top: 15px;

However, you may have also come across more cryptic style definitions like these but wonder which measurement applies to which side of the element:

padding: 1px 2px 3px 4px;
padding: 5px 6px 7px;
padding: 8px 9px;
padding: 10px;

Here’s a key for decoding these definitions:

padding:   top   right   bottom   left;
padding:   top   right/left   bottom;
padding:   top/bottom   right/left;
padding:   top/bottom/right/left;

This same pattern applies to margins and borders.

Aside from the cryptic definitions, see my other post displaying how the CSS Box Model treats margins, borders, and padding with respect to width and height dimensions.  If you are an ADF Faces application developer be sure to also read the Layout Basics page.

Your Bank and Employer are Putting Your Security at Risk

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:

1. 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.
2. 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.

CSS Spec Proposals for Transforms, Transitions, and Animation

The folks at webkit.org are adopting animation support that has been present in mobile Safari since iPhone 2.0. They are also proposing specs for CSS-based transforms, transitions, and animations:

• http://www.w3.org/TR/css3-2d-transforms/
• http://www.w3.org/TR/css3-3d-transforms/
• http://www.w3.org/TR/css3-transitions/
• http://www.w3.org/TR/css3-animations/

See some animations in action using the latest nightly WebKit at:

• http://webkit.org/blog/324/css-animation-2/

Firefox 3.1 is also adopting WebKit’s proposal for supporting transforms too:

• https://developer.mozilla.org/web-tech/2008/09/12/css-transforms/

And of course there is also the cryptic filters that IE supports for transforms:

• http://msdn.microsoft.com/en-us/library/ms533014(VS.85).aspx

It will be nice to have all of these varying implementations conform to a standard.