I would say because the mini is currently 1 year old. Before that we had iPhone and iPad and they had their own per-type resources in storyboard or nib or xib. The switch to a slightly larger iPhone screen was in most cases very elegantly sorted out with autolayout, a technology Apple conveniently introduced at the time, and it works very well. Basically you designed your nib for a device and the size of the controls, in physical terms, didn't change much.
Then came the mini. I think there was a reasonable belief that the iPad original size vs iPad mini size wouldn't be an issue. You have the same number of points (and now pixels) on the screen, controls are a little smaller physically but it normally works just scaled, it certainly has for the other projects I have which are deployed on mini. That was a pretty good base case assumption. I finally got to a project where the physical on-screen size of an element makes some difference. So I filed the bug report with the use-case and I hope that there will one-day be an API point for this so views which really care about size can be .. that size (someone surely has wanted to make an iPad ruler, there's a great use-case). Until then, re-designing that one screen for the mini and letting it scale up for the normal iPad worked very well, so perhaps Apple were right in the first place, one iPad size does fit all, just not the size I started with. I stick to public APIs, file bug reports when I think it's lacking and attempt to follow the advice of Apple engineers even when it seems there's a cheap and easy way around them, that normally leads to the most maintainable, sustainable, code. On 26 Nov, 2013, at 10:16 pm, Maxthon Chan <xcvi...@me.com> wrote: > Then why the hell in the five years of public iOS API, Apple always decided > against a public API point for that? > > To me, I think an API like that suggests possible fragmentation just like > what plagued the system you-know-what and Apple clearly does not want that > come into happening. Also, reading identifiers for released devices can be > quite accurate. > > On Nov 26, 2013, at 21:45, Roland King <r...@rols.org> wrote: > >> Rubbish. >> >> And any reading of the Apple Dev Forums will find many messages from Apple >> engineers telling you NOT to do that, NOT to guess, NOT to make assumptions >> based on what you think identifiers are or are going to be and to stick to >> the API points there are. They also ask people file bug reports with use >> cases about why one might need the physical device screen size, which I have >> done. >> >> On 26 Nov, 2013, at 9:41 pm, Maxthon Chan <xcvi...@me.com> wrote: >> >>> There is no reason for Apple to provide such an clearly redundant API >>> point. Developers can somehow predict the new devices’ identifiers and the >>> sizes are largely correctly guessed so a quick table look-up will work very >>> well. >>> >>> On Nov 26, 2013, at 21:38, Igor Elland <igor.ell...@me.com> wrote: >>> >>>>> If there isn't a proper API point for it, then I'm not doing it. >>>> >>>> I’m quite sure there’s no public API to get the physical screen size or >>>> otherwise differentiate between the regular size screen iPad and the mini. >>> >> > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
