If you read the data sheet I sent, you will find out that iPad mini have the same pixel density as iPhones, iPad mini 1G = iPhone 2G and iPad mini 2G = iPhone 4. So the situation would be that on iPad mini the developers may want to use iPhone-sized UI with an iPad-sized layout.
On Nov 26, 2013, at 22:51, Roland King <r...@rols.org> wrote: > 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
