Maybe you can refer to
[UIScreen mainScreen].scale and [UIScreen mainScreen].bounds
The scale tells you the pixels per point.
The bounds provides you the whole screen size in point.
To get the real size per pixel:
scale * bounds
Cheers
Jack.S Mu
2013/11/25 Roland King
> Is there yet a sup
no that just gives you the total number of pixels on the screen, I know that,
that's not a problem.
That is not the screen physical size (ie X cm x Y cm) and you can't figure out
if you want something to be a given physical size, which I did, how many points
it should be. In order to know the
Well you just need to detect the device and the numbers are constant:
Screen information:
iPhone 2G/3G/3GS, iPod touch 1G/2G/3G: 320x480px, 163dpi
iPad mini 1G: 1024x768px, 163dpi
iPhone 4/4S, iPod touch 4G: 640x960px, 326dpi
iPhone 5/5C/5S, iPod touch 5G: 640x1136px, 326dpi
iPad mini 2G: 2048x1
No I clearly said in my very first message
"I know there was lots of chat about this when the mini came out, there
wasn't anything then and I don't want to do one of the version or device name
hacks. Is there yet an API point for this? "
If there isn't a proper API point for it, then I
There is not any known public API for that. You can use the device type reading
as a default and offer user an calibration option.
On Nov 26, 2013, at 21:34, Roland King wrote:
> No I clearly said in my very first message
>
> "I know there was lots of chat about this when the mini came
> 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-de
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 wrote:
>> If there isn't a p
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 rep
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, readin
Can we have a moderator here closing this thread? It clearly devolved into
ramblings against policy.
___
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
> Then why the hell in the five years of public iOS API, Apple always decided
> against a public API point for that?
>
Probably because there’s no way to accurately know the physical screen size of
a device attached via AirPlay or HDMI cable. The API would break in such cases.
(And the same
> Probably because there’s no way to accurately know the physical screen size
> of a device attached via AirPlay or HDMI cable. The API would break in such
> cases.
>
> (And the same argument applies to adding more / less content on iPad mini
> screen because of its physical dimensions. It’s a
So I think here is the equation:
If you need precise device size, you have to rely on device model, for both
built-in and external screens.
To make that mapping possible, you need some method of reading the device model
and search a database.
Reading model number is easy for main device screen a
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 convenient
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
On 26 Nov 2013, at 15:51, Roland King wrote:
> 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 think followi
On 26 Nov 2013, at 12:53 AM, Rick Mann wrote:
> On Nov 25, 2013, at 21:11 , Luther Baker wrote:
>
>> Maybe I am missing something - but I just created a new Tab based project
>> and dropped a UITableView directly on the FirstViewController, under the
>> "View" node in the expanding tree. If I r
Your data sheet is pointless if there is no way, using public, future-proof,
Apple-provided API, to reliably figure out where in that datasheet you are. If
I wanted to hack my way around the Apple ecosystem I wouldn't have asked the
question, I'm perfectly capable of tabulating current devices,
"Design for mini" I agree with. I never had a mini before last weekend and
didn't realise what looked great on a full-size didn't work scaled down but
what looked great on a mini still looked ok scaled up. I'm going to be just as
conscious of mini vs normal as I have been iPhone vs iPad paradigm
I need to remove hidden files from removable media and have been doing so
successfully until 10.9.
I use NSTask as follows:
NSTask *task;
task = [[NSTask alloc] init];
[task setLaunchPath:rootScriptPath];
[task setArguments:[NSArray arrayWithObjects:rootpath, nil]];
[task waitUntilExit];
On Tue, Nov 26, 2013, at 07:47 AM, koko wrote:
> This works just fine up to and including 10.8.5 BUT throws an exception
> at [task launch] on 10.9
What is the exception?
--Kyle Sluder
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do
Why would you delete files in this manner? It's more efficient to delete them
directly from your Objective C code, thus:
NSArray *fileArray = [@"path1",@"path2"];
for (NSString *filename in fileArray)
{
[fileMgr removeItemAtPath:filename error:NULL];
}
You already know wh
Right, that seems obviously like fighting the SDK.
My suggestion is around rolling your own. IE, I would wire up and drop a
"UITableView" on a parent view controller, I wouldn't drop a
"UITableViewController" on a parent.
For the most part, UITVC is a convenience view controller. If it doesn't
On Nov 26, 2013, at 8:56 AM, Pax <45rpmli...@googlemail.com> wrote:
> hy would you delete files in this manner?
Need to wildcard the file names.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator com
On Nov 26, 2013, at 9:42 AM, koko wrote:
>
> On Nov 26, 2013, at 8:56 AM, Pax <45rpmli...@googlemail.com> wrote:
>
>> hy would you delete files in this manner?
>
> Need to wildcard the file names.
Get the directory contents and look for matches, or use glob.
--
Scott Ribe
scott_r...@eleva
I’d like to say just get rid of the old iPad-sized control design and embrace
iPhone-sized controls with iPad-styled layout - they will look good on both
iPad mini and iPhone since they have the same pixel (point) density and when
regular iPads are used, despite being sub-optimal, the UX will no
So:
NSFileManager *fileMgr = [NSFileManager defaultManager];
NSArray *contents = [fileMgr contentsOfDirectoryAtPath:
error:nil];
for (NSString *item in contents)
{
if ([item rangeOfString:].location !=NSNotFound)
{
[
On Tue, Nov 26, 2013, at 09:37 AM, koko wrote:
>
> On Nov 26, 2013, at 10:26 AM, Kyle Sluder wrote:
>
> > Error 2 is ENOENT. The path you passed to -setLaunchPath: does not exist.
> >
>
>
> Not possible as
>
> [task setLaunchPath:rootScriptPath];
>
> where rootScriptPath is NSString *rootS
This distinction between iPad-sized controls and iPhone-sized controls is
confusing. On either platform, the guideline has always been to prefer 44
pt by 44 pt touch targets. The iPad having a lower pixel density than the
iPhone (when comparing screens of the same scale) is balanced by users
holdin
On Nov 26, 2013, at 08:12 , Luther Baker wrote:
> For the most part, UITVC is a convenience view controller. If it doesn't work
> out of the box, not hard to roll your own and get the behavior you are
> looking for ... Even still with Xibs.
Unfortunately, this does not work if you want to use
On Nov 25, 2013, at 21:16 , Luther Baker wrote:
> Does the UITableViewController provide something more I'm not seeing?
Yes. Support for static (and probably dynamic) cells.
I'm implementing this using view controller containment, but it's
extraordinarily cumbersome. First, the non-scrolling
Augh, it's even worse than I thought. The embedded view controller doesn't get
to set the navigation bar's items from IB. This is a terrible solution.
On Nov 26, 2013, at 11:32 , Rick Mann wrote:
>
> On Nov 26, 2013, at 08:12 , Luther Baker wrote:
>
>> For the most part, UITVC is a convenien
> Dynamically at runtime, I'd like to put a fixed banner across the top of a
> UITableViewController scene with some status information. I want this banner
> to remain fixed at the top, and for the UITableView to live in a frame below
> it.
>
Probably I’m missing something or I’m just naïve (
On Nov 26, 2013, at 19:18 , Marcelo Alves wrote:
> Probably I’m missing something or I’m just naïve (or stupid), but what about
> the tableHeaderView (or tableFooterView) property? (not the same as section
> headers)
It scrolls with the table content.
--
Rick
signature.asc
Description:
On Nov 26, 2013, at 9:47 AM, koko wrote:
> NSTask *task;
> task = [[NSTask alloc] init];
> [task setLaunchPath:rootScriptPath];
> [task setArguments:[NSArray arrayWithObjects:rootpath, nil]];
> [task waitUntilExit];
> [task launch];
> [task release];
You have the invocation of -launch and -wai
> On Nov 26, 2013, at 6:06 PM, Rick Mann wrote:
>
> Augh, it's even worse than I thought. The embedded view controller doesn't
> get to set the navigation bar's items from IB. This is a terrible solution.
>
Yeah, this is getting more and more tedious.
My guess is there's a lot of code out the
In my ongoing experimentation with getting a fixed view above my table view,
I'm trying to do what I did successfully in the days before autolayout:
separate the UITV's view and tableView properties. This works, but I can't
figure out how to make it work with autolayout constraints.
The problem
37 matches
Mail list logo
