You are currently browsing the category archive for the ‘mac’ category.
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.
Ever wanted to easily reveal a file that you’re working on in JDeveloper in the Mac OS X Finder?
Here’s how to set up a toolbar button and context menu item to do just that:
- Go to Tools – External Tools
- Click New…
- Choose these settings:
Type = External Program
Executable = open
Arguments = -R ${file.path}
Caption = Show in Finder
Add Item to Menus = Tools Menu, Window Context Menu, Source Editor Context Menu
Add Buttons to Toolbars = Main Toolbar
Log Output to Messages Log = unchecked
Enabled = When a file is selected or open in the editor
Once you’ve created that tool, simply right-click a file in the application navigator, right-click an editor, or use the toolbar button to switch to have JDeveloper automatically switch over to the Finder and open a window with that file selected.
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.
Prior to Mac OS X 10.8 Mountain Lion, you could open Applications/Utilities/Console.app, pick the log called “secure.log” and then see whenever you recently logged in or unlocked your screen saver (with a password).
Starting in Mountain Lion, secure.log doesn’t exist anymore.
Now, that same information is available via an Applications/Utilities/Terminal.app shell command:
syslog -k Time ge -10h | egrep -e 'loginwindow'
This will get all of the syslog records chronologically for the last 10 hours and filter that with the term “loginwindow”. Based on that, you can then see each time you logged in–like what secure.log used to provide.
In Mac OS X, if someone gives you a Linux path that looks like:
/net/server/path/to/some/folder/
you can load that folder by swapping out “/net/” with “nfs://” and using a feature of the Mac OS X Finder. In the Finder, go to:
Go - Connect to server...
And then specify the server address of:
nfs://server/path/to/some/folder/
If you are allowed to connect, a drive will be mounted on your desktop.
On a related note. If you are using Firefox and come across one of these “nfs://” URLs, Firefox may not automatically mount the drive for you or even prompt you for an application to handle that URL. Instead, you will need to tell Firefox that you want the Finder to handle those kinds of URLs.
I have tested these instructions on Firefox 3.6:
- In Firefox’s address bar, go to:
about:config
- If you have never been there before, it might warn you about editing these settings.
- Once you get past the warning and can see a table listing all of your browser settings, right-click anywhere in that table and choose:
New - Boolean
- For the name, specify:
network.protocol-handler.expose.nfs
- For the value, specify:
false
The next time you try to click one of those links, Firefox will prompt you for a program to handle it and then that program will launch the appropriate network drive. At least on a Mac, you will need to choose:
/System/Library/CoreServices/Finder.app
Additional information on protocol handling in Firefox can be found at:
