What is a web inspector?
Apple introduced the ability to use the desktop Safari web inspector developer tools with iOS application WebViews and mobile Safari back in iOS 6 and Safari 6. Each new release of iOS has required that you use a corresponding version of desktop Safari so beware of this if you are planning to upgrade one device but not the other.
Google introduced the ability to use the desktop Chrome web inspector developer tools with Android application WebViews and mobile Chrome in Android 4.4 when the Chrome WebView was introduced. Many legacy Android devices are still being sold (let alone in use) but unfortunately, it is not compatible with the web inspector. For situations like that, there are some third party techniques available that require you to inject code into your application in order to send messages back and forth with a server. Those solutions have much fewer abilities than a formal web inspector. To combat this legacy issue, Google introduced a Google Play-updatable WebView in Android 5 Lollipop so your application can take advantage of new technologies even if the OS is not upgradeable.
This post only discusses web inspectors. If you are interested in debugging Java code for your application, refer to the Oracle MAF developer guide for instructions.
Setting up your Oracle MAF Application
For iOS, there is no property to edit, you either need to use a debug deployment or use Xcode to run the application. For Android, you must edit the src/META-INF/maf.properties file of your application so that it defines:
You can only use a web inspector with development (aka non-production) applications.
If you want to connect the web inspector before the first screen loads, will need to edit your run configuration’s “Application Arguments” to specify the following which allows you to configure how many seconds before the WebView will get populated with content.
If doing this in an already-generated Xcode project, this setting goes in the Run Scheme’s “Arguments Pass On Launch” field.
Setting up your Desktop Browser
I assume that you already have your device set up for development so I won’t cover it here (e.g. Android needs development mode and USB debugging turned on via tapping the build number 7 times, iOS needs the device set up as “Use for development”, etc.).
Desktop Chrome doesn’t require anything special but I use this optional “ADB” Chrome extension as a convenience since I find it easier to click an icon vs. typing a special URL in the address bar.
Desktop Safari requires you to enable the “Develop” menu in its Advanced Preferences dialog:
Using the Safari Web Inspector
From the Safari Develop menu, your connected devices and iOS Simulator will display as submenus. Each submenu will list all of the WebViews that you are allowed to inspect (if you are not sure which one you want, a light blue highlight will appear on your device or in the simulator as you hover over each menu item).
A web inspector window will open once you select that menu item:
The UI varies across versions of desktop Safari but I’ll describe one here as an example. The “Resources” tab (1) is where you can browse the DOM, look at scripts, style sheets, etc. When the HTML resource is selected, the main panel will show you the DOM tree (3) which you can manually browse for an element. Alternatively, you can use the crosshairs 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 “Styles” tab (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 inspected element (5). This is incredibly valuable, particularly when multiple selectors are competing (a line will strike out any styles that lose out 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. Beware changes made in the inspector do not get saved permanently into your application. 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.
Using the Chrome Web Inspector
First, visit Chrome’s “chrome://inspect/#devices” page to see a list of your connected and debuggable Android devices. Each will appear with all of the WebViews that you are able to inspect. An icon will appear with a darker gray and the WebView listed towards the top will be what is currently visible on the Android screen.
A web inspector will open once you click the “inspect” link.
The UI varies across versions of desktop Chrome but I’ll describe one here as an example. The “Elements” tab (1) is where you can browse the DOM. The main panel will show you the DOM tree (3) which you can manually browse for an element. Alternatively, you can use the magnifying glass tool (2) to click on the screen (of the actual device or the emulator) to pick an element that you want to inspect.
With an element selected, you can then use the “Styles” tab (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 inspected 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. Beware changes made in the inspector do not get saved permanently into your application. 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.
The content of this post has been updated with additional detail at:
It may be tempting to go crazy with panelGroupLayout components in ADF Faces and ADF Mobile. The panelGroupLayout is not the universal hammer. In many cases, you will have a simpler structure (easier to maintain, more predictable, faster performing, more flexible) if you build your structure using a panelGridLayout or tableLayout instead.
When you are given a mock-up of what the application should look like, you may not know how to break it down into something simple. Either print out the design on a piece of paper or open it up in a graphics program where you can draw some lines.
- Draw vertical lines representing potential column divisions (red)
- Draw horizontal lines for potential row divisions (green)
- Now that you have a basic grid structure, use a different color (yellow) to draw x marks where you see cells that need to span multiple columns or rows:
- You may find that your column lines really don’t make sense (in this case, the 2 middle columns had no cells in them that didn’t need to span into a nearby column. This is an indication that there probably ought to be 2 separate grids or tables. Use a new color (magenta) to draw a line where the division makes sense and repeat the process again:
Now you can go back to coding your gridRow/gridCell or rowLayout/cellFormat components because you can visually see where the content goes and where you need to use a special columnSpan or rowSpan. As an added bonus, you now have the ability to specify the sizes for your cells as well as the horizontal and vertical alignments of your cells–something panelGroupLayout would not allow you to control.
Notice that the labels and fields of grid 2 (columns 1 and 2) are showing separate components. This is done so that there can be matching horizontal alignment among the fields of the two rows. If these were input or select components, you would need to use simple=”true” (to hide the built-in label) and then use separate outputLabel components that reference them.
While we are only using consecutive grids in the example discussed in this article. You might come across a need to nest a grid inside of another grid. Do not excessively nest panelGridLayout nor tableLayout components (if you have 3 or more deep, consider a re-evaluation of your structure). You may find it helpful if someone else reviews your structure. Your goal should be to create something simple.
Whether you are developing a MAF (or ADF Mobile) application or a classic ADF Faces 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 (sometimes referred to as a “dp” or density-independent pixel) corresponds to the same amount of space regardless of the DPI of your screen (however, the number of screen 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 screen pixels in the same amount of space that 1 screen pixel used to take up (2 screen pixels wide by 2 screen pixels tall); on these new screens, the width and height “px” values use twice the amount of screen pixels.
Why is this a common problem? Since MAF (or 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 screen 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 screen 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 screens 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 screen, you have the option to use a screen 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.
PNG vs. SVG?
Consider whether using PNG is really the right choice to begin with. SVG (scalable vector graphics) files tend to be smaller file sizes when created without excessive anchor points, no embedded bitmap data, reduced decimal number precision, excess whitespace removed, and comments removed. If the resolution of your display gets better, the SVG will look that much better; you don’t need multiple resolution versions of the same image resources. If the SVG was given the proper width/height to begin with by its creator, you won’t even need to muck with inlineStyles since the image will naturally be displayed at the proper size.
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.