This promise though has recently been discussed controversially (e.g. ATP) with keywords being Pixel Density, Screen Space, Retina Resolution, HiDPI Modes.
Here is my take.
Targeted at their Retina displays Apple has introduced specific screen resolutions they call “HiDPI Modes”. Instead of rendering one pixel per point of a user-chosen screen resolution of x by y points these modes render 2 by 2 pixels per point. This naturally results in a much sharper display specifically when using screen resolutions below the physical screen resolution of a display. And this is the standard use case with Retina displays on Macbook Pros and probably 4K displays since they offer such high pixel densities you wouldn’t want to choose the physical screen resolution as your actual resolution.
There is one specific HiDPI mode referred to as the Retina resolution which is the screen resolution that is exactly half the resolution of the physical screen. I.e. since being HiDPI it renders exactly the amount of pixels of the physical screen. It is sometimes also referred to as the @2x resolution.
Some people argue that this clearly is the preferred resolution to choose from using a retina screen since it best “matches” its physical screen resolution (read: delivers the best sharpness). Although mathematically there may be some truth to it I have found that in practice it doesn’t matter. You will hardly be able to pick any other HiDPI mode OS X provides and call it out to provide less sharpness than the retina resolution. Apple has done a tremendous job on this.
The above being said and assuming HiDPI modes being sufficiently available for a 4K monitor you could argue that
There is of course a performance penalty for using higher resolutions in general and it is the job of the graphics card and the data bus to handle that.
We’ve got high performance graphics cards and thunderbolt2 delivered with the above mentioned computer models but it seems that much awaited display modes like 2560x1440 HiDPI still surpass their capabilities. Specifically Thunderbolt2 doesn’t seem capable of transferring 2560x1440 HiDPI mode data at reasonable rates to a monitor (See joshjet’s tweet). And I doubt that HDMI would do any better (but would love to be proven wrong).
Anyhow, If you want to judge roughly what display sharpness you will get from a hypothetical 27” 4K monitor (it has a pixel density of about 163 ppi) place your non-retina iPad mini at same distance and height in front of you as you place your regular monitor, hook up a keyboard to the iPad and start typing within your preferred editor.
]]>In my understanding such feature goes against the principle of keeping things as simple as possible. Offering the concept of paid upgrades adds complexity to a selling policy. “Why do I have to pay for this upgrade and not for that one?” “Why is this guy eligible for discounted upgrade and I am not?” I am not saying this is not manageable but do we need paid upgrades? I think not.
Apple itself has long adopted a selling policy for its own sofware products that adheres to the following principles:
Simple. Here, Apple again lives up to its core value of embracing simplicity. Yet, people argue that customers will not take to pay the same price for a product they already bought an evolutionary ancestor of as somebody else paid who did not. They argue that former customers will feel (or even are?) being ripped off. I my view discussing this issue is a hopeless endeavor because product pricing in the first place is driven by all kind of factors and “fair” is most often interpreted as “marketable”. I do want to note though that not offering discounted upgrades should make room for a lower product price.
Why do customers feel being ripped off? It is because they are so used to a selling policy that does offer discounted upgrades. But policies are not by nature but offer advantages and disadvantages. It is benficial to a customer not having to deal with the circumstances of “upgrades”. The goal of a simpler selling policy is not to generate more revenue for the selling company but to keep things simple. In the end the whole set of customers of a “series” of product evolutions should pay the same in total. Individual customers (e.g. the ones that buy the whole series) may pay more than when being offered discounted upgrades. But they are probably also the ones drawing the highest value from the product.
Apple has proven so many times that it’s worth it to leave legacy behind. And by the way, I never felt ripped off rebuying iWork XY given its relatively low price. And I could even skip one evolutionary step without losing eligibility for a discounted upgrade.
First, customers must get the reasoning behind Apple’s simple selling policy. I my view it is Apple’s call to reach out and let them know. And yes, app developers are customers. Then product selling companies should chime in.
Second, Apple should provide a means to communicate to existing buyers when a descendant of a bought product has arrived in the App Store and make the transition between product evolutions easy as pie for buyers and developers (even more so in the era of sandboxing). Regarding this Wil Shipley already proposed a good starting point to a solution.
]]>This is because Apple’s whole concept of sandboxing/entitlements is not complete and different OS X versions have different suppport for sandboxing.
Let’s take a closer look at different scenarios.
There is no concept of app sandboxing in 10.6.x. A sandboxed app should run as if not sandboxed. Yet Developers must ensure not to apply sandbox related API (this is developer best practice).
There currently seem to be two main feasible strategies to adopt sandboxing:
Strategy: “Early Feedback” (more predictability, more work)
BTW: I have not found any recent evidence that Apple would rather grant your app some temporary entitlement if that entitlement was isolated in a single purpose XPC Service. All questions about this being asked in Apple’s developer forum went unanswered (to my knowledge).
This approach is viable only if the following conditions are met:
Strategy: “Wait and Wonder” (less work, less predictability)
Here, the following conditions must be met:
You will have noticed that either strategy is somewhat depending on versioned sandboxing / versioned entitlements like
Apple has not provided such mechanism yet.
If you are an affected developer or you sympathize with an affected developer you should (should I say must?) file a bug report regarding this omission to Apple (e.g. like Daniel Jalkut did). This will encourage Apple to provide such means with high priority.
]]>After thoroughly digging into it and appointing Instruments to help me on this I was finally convinced that my code in fact was balanced in terms of reference counting. This problem was to be blamed on the other usual suspect: Apple. Thanks to the Allocations instrument I finally figured out:
The number of live nodes always increased by at least one after I triggered the node replacement operation if and only if the old node was the selected item in the tree before being replaced. Since the old node was properly released due to being removed from the array it was (solely) referenced from the only possible explanation was that the associated NSTreeController was still retaining it.
I know, it’s a widespread vice of looking for somebody else to blame instead of keeping your own backyard tidy, but a small test project I set up makes it rather obvious that NSTreeController (as of 10.7.2) is in fact to be held accountable for this leakage. Luckily, there is a simple workaround to the problem which is to programmatically deselect a node in the NSTreeController before replacing it.
If you are interested in the sweaty details find them here.
]]>Fortunately the ever knowledgeable Mike Ash has written an excellent blog post on ARC as a whole and toll-free bridging in particular which I strongly recommend to read. Drawing on this I will rephrase the bottom line on bridged casts in a rather informal but still catchy manner right here.
So, what is ARC concerned about when your program turns an Objective-C object pointer into some C type pointer and vice versa? It’s interest is all about:
Who takes care of releasing that object later on? You the programmer or me, ARC?
Well, you can tell ARC via the following cast modifiers:
__bridge_retained (n.b.: only use it when casting from object pointer to C type pointer): I (the programmer) need to reference this object for some time in the dark world of C type pointers which is opaque to you, ARC. So please, please do not release this object while I still need it. I (the programmer) promise to release it myself (in the dark world) when I’m done with it
__bridge_transfer (n.b.: only use it when casting from C type pointer to object pointer): I (the programmer) hand over to you, ARC, an object that I own and that I am no longer interested in in the dark world of C type pointers that is opaque to you. Whenever you, ARC, are done with that object please release it yourself, because you know the right time and thus save me some work not having to do it myself.
__bridge: ARC, you keep balancing out your retains and releases as I keep balancing out mine in the dark world of C type pointers which is…. Whenever I need to hold on to an object in the dark world I will retain it myself and release it when appropriate. I don’t need any extra contract with you, ARC.
Mike Ash also excercises excellent examples to illustrate these three semantics.
]]>As a host application’s programmer you have to exercise the following steps to utilize this functionality.
Implement the following method in your host application’s delegate
- (CGImageRef) objectViewController:(IMBObjectViewController*) inController badgeForObject:(IMBObject*) inObject
Given an object and a corresponding controller you will have to provide a badge image back to the browser. A typical badge would be a checkmark or a circled number (denoting things like “Item is being used” or “Item is being used n times”). If you return NULL the object won’t be badged. Most often you will keep a dictionary around holding those objects to be badged keyed by some object identifier that is also known to the respective object inside the browser (-[IMBObject identifier] would be such a key candidate).
The badge image will be drawn in 3 different views that embed media objects: the icon view (≥ OSX 10.6), the list view and the combo view. Because the list view sports a mere height of 17 pixels per row and since badge images will not be scaled in any way by the browser framework an image size of 16 pixels square is generally a good choice. You find an exemplary implementation of the method in IMBTestAppDelegate.
To keep your implementation of the method performant (it will get called at least once on any object to be displayed) it is good practice to cache badge images.
To signal changes on badges to the framework send a
setObjectContainerViewNeedsDisplay:YES
message to all IMBNodeViewController objects that your app instantiated. If you intended to implement the “Item is being used” type of badge a typical initial badge-changing trigger would be a drag and drop operation of media objects from the browser into a view of your app (see an exemplary implementation on how to handle that in IMBTestTextView. Subsequent possibly badge-changing (user) actions then would be (list considered incomplete):
It is definitely the host application’s programmer’s responsibility to attach a notification to the framework to such actions. Note that handling of the actions from above is not excercised by the browser test app.
Responsibilities for getting badges to work are shared among a couple of objects:
An IMBNodeViewController: tells its currently visible object view that it must redraw itself (triggered by the host application)
→ setObjectContainerViewNeedsDisplay:
An IMBObjectViewController: is the one that asks its delegate for an appropriate badge whenever an object will have to be displayed or when it is to be decided wether the object will be displayed at all (badge related filters). Being the view’s delegate it prepares the view (resp. a view cell) for drawing.
→ willDisplayCell:forTableColumn:row:
→ objectArrayController:filterObject:
→ -[<IMBObjectViewControllerDelegate> objectViewController:badgeForObject:]
An IMBObjectArrayController: asks the object controller whether an object passes the badge filter test.
→ arrangeObjects:
A View: can be either an IMBImageBrowserView, an IMBComboTableView, or an IMBDynamicTableView. It is responsible for actually drawing the badge it got via the controller.
→ -[IMBImageBrowserCell layerForType:]
→ -[IMBComboTextCell _drawImage:withFrame:]
It is worth mentioning that the framework does not keep any badging information in its state (aside from a volatile reference to a badge image in a view cell). Thus, the framework must always query the host application’s delegate for appropriate badges. The upside of this design decision is that it is easier to keep the framework’s and the host application’s state in sync compared to storing badge information with the framework’s media objects. The downside obviously is that it is less performant.
]]>