Re: iOS screen physical size (or px density)
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 r...@rols.org Is there yet a supported way of finding out the actual screen size (or equivalently pixel density) on an iOS screen? I have an app, uses autolayout, works fine on iPhone (one storyboard), iPad (another storyboard) and mostly looks fine between iPad and iPad mini. One screen however has a number of test 'cards' on it. On the phone one card == one screen looks great. On a full-sized iPad, about 6 to a page is clear, on a mini however 6 is not ideal and 4, or 3, looks much better and is much clearer to test. That's one of the fairly rare cases where one size doesn't fit all and knowing the actual screen dimensions would make a better user experience. 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? ___ 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/jackyseraph%40gmail.com This email sent to jackyser...@gmail.com ___ 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
Re: iOS screen physical size (or px density)
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 physical screen size you would need an API point which either returns it directly, or returns the pixel density in px/cm. Anyway I went with the suggestion of an earlier poster and scaled up so it was nearly as big as I wanted on the mini, and bigger than I really wanted on the iPad, both using the same pointsize for the elements. And that's not a bad compromise (in fact on the larger iPad the bigger test cards are very clear and you don't really notice they are .. a bit huge). Problem solved, one interface for either of the two sizes of iPad, and the iPhone was never a problem. I still would like that API point, I shall file a bug which will be duped. On 26 Nov, 2013, at 4:18 pm, Jacky.Seraph Mu jackyser...@gmail.com wrote: 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 r...@rols.org Is there yet a supported way of finding out the actual screen size (or equivalently pixel density) on an iOS screen? I have an app, uses autolayout, works fine on iPhone (one storyboard), iPad (another storyboard) and mostly looks fine between iPad and iPad mini. One screen however has a number of test 'cards' on it. On the phone one card == one screen looks great. On a full-sized iPad, about 6 to a page is clear, on a mini however 6 is not ideal and 4, or 3, looks much better and is much clearer to test. That's one of the fairly rare cases where one size doesn't fit all and knowing the actual screen dimensions would make a better user experience. 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? ___ 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/jackyseraph%40gmail.com This email sent to jackyser...@gmail.com ___ 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
Re: iOS screen physical size (or px density)
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: 2048x1536px, 326dpi
iPad 1G/2: 1024x768px, 132dpi
iPad 3G/4G/Air: 2048x1536px, 264dpi
Device model identifier (readable from uname(2)):
iPhone1,1 = iPhone 2G
iPhone1,2 = iPhone 3G
iPhone2,1 = iPhone 3GS
iPhone3,* = iPhone 4
iPhone4,1 = iPhone 4S
iPhone5,{1..3} = iPhone 5
iPhone5,{4..6} = iPhone 5C
iPhone6,* = iPhone 5S
iPod1,1 = iPod touch 1G
iPod2,1 = iPod touch 2G
iPod3,1 = iPod touch 3G
iPod4,1 = iPod touch 4G
iPod5,1 = iPod touch 5G
iPad1,1 = iPad 1G
iPad2,{1..4} = iPad 2
iPad2,{5..7} = iPad mini 1G
iPad3,{1..3} = iPad 3G
iPad3,{4..6} = iPad 4G
iPad4,{1..3} = iPad Air
iPad4,{4..6} = iPad mini 2G
On Nov 26, 2013, at 16:57, Roland King r...@rols.org wrote:
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 physical screen size you would need
an API point which either returns it directly, or returns the pixel density
in px/cm.
Anyway I went with the suggestion of an earlier poster and scaled up so it
was nearly as big as I wanted on the mini, and bigger than I really wanted on
the iPad, both using the same pointsize for the elements. And that's not a
bad compromise (in fact on the larger iPad the bigger test cards are very
clear and you don't really notice they are .. a bit huge). Problem solved,
one interface for either of the two sizes of iPad, and the iPhone was never a
problem.
I still would like that API point, I shall file a bug which will be duped.
On 26 Nov, 2013, at 4:18 pm, Jacky.Seraph Mu jackyser...@gmail.com wrote:
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 r...@rols.org
Is there yet a supported way of finding out the actual screen size (or
equivalently pixel density) on an iOS screen?
I have an app, uses autolayout, works fine on iPhone (one storyboard), iPad
(another storyboard) and mostly looks fine between iPad and iPad mini. One
screen however has a number of test 'cards' on it. On the phone one card ==
one screen looks great. On a full-sized iPad, about 6 to a page is clear, on
a mini however 6 is not ideal and 4, or 3, looks much better and is much
clearer to test. That's one of the fairly rare cases where one size doesn't
fit all and knowing the actual screen dimensions would make a better user
experience.
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?
___
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/jackyseraph%40gmail.com
This email sent to jackyser...@gmail.com
___
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/xcvista%40me.com
This email sent to xcvi...@me.com
___
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
Re: iOS screen physical size (or px density)
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'm not doing it.
On 26 Nov, 2013, at 9:20 pm, Maxthon Chan xcvi...@me.com wrote:
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: 2048x1536px, 326dpi
iPad 1G/2: 1024x768px, 132dpi
iPad 3G/4G/Air: 2048x1536px, 264dpi
Device model identifier (readable from uname(2)):
iPhone1,1 = iPhone 2G
iPhone1,2 = iPhone 3G
iPhone2,1 = iPhone 3GS
iPhone3,* = iPhone 4
iPhone4,1 = iPhone 4S
iPhone5,{1..3} = iPhone 5
iPhone5,{4..6} = iPhone 5C
iPhone6,* = iPhone 5S
iPod1,1 = iPod touch 1G
iPod2,1 = iPod touch 2G
iPod3,1 = iPod touch 3G
iPod4,1 = iPod touch 4G
iPod5,1 = iPod touch 5G
iPad1,1 = iPad 1G
iPad2,{1..4} = iPad 2
iPad2,{5..7} = iPad mini 1G
iPad3,{1..3} = iPad 3G
iPad3,{4..6} = iPad 4G
iPad4,{1..3} = iPad Air
iPad4,{4..6} = iPad mini 2G
On Nov 26, 2013, at 16:57, Roland King r...@rols.org wrote:
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 physical screen size you would
need an API point which either returns it directly, or returns the pixel
density in px/cm.
Anyway I went with the suggestion of an earlier poster and scaled up so it
was nearly as big as I wanted on the mini, and bigger than I really wanted
on the iPad, both using the same pointsize for the elements. And that's not
a bad compromise (in fact on the larger iPad the bigger test cards are very
clear and you don't really notice they are .. a bit huge). Problem solved,
one interface for either of the two sizes of iPad, and the iPhone was never
a problem.
I still would like that API point, I shall file a bug which will be duped.
On 26 Nov, 2013, at 4:18 pm, Jacky.Seraph Mu jackyser...@gmail.com wrote:
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 r...@rols.org
Is there yet a supported way of finding out the actual screen size (or
equivalently pixel density) on an iOS screen?
I have an app, uses autolayout, works fine on iPhone (one storyboard), iPad
(another storyboard) and mostly looks fine between iPad and iPad mini. One
screen however has a number of test 'cards' on it. On the phone one card ==
one screen looks great. On a full-sized iPad, about 6 to a page is clear,
on a mini however 6 is not ideal and 4, or 3, looks much better and is much
clearer to test. That's one of the fairly rare cases where one size doesn't
fit all and knowing the actual screen dimensions would make a better user
experience.
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?
___
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/jackyseraph%40gmail.com
This email sent to jackyser...@gmail.com
___
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/xcvista%40me.com
This email sent to xcvi...@me.com
___
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
Re: iOS screen physical size (or px density)
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 r...@rols.org wrote:
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'm not doing it.
On 26 Nov, 2013, at 9:20 pm, Maxthon Chan xcvi...@me.com wrote:
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: 2048x1536px, 326dpi
iPad 1G/2: 1024x768px, 132dpi
iPad 3G/4G/Air: 2048x1536px, 264dpi
Device model identifier (readable from uname(2)):
iPhone1,1 = iPhone 2G
iPhone1,2 = iPhone 3G
iPhone2,1 = iPhone 3GS
iPhone3,* = iPhone 4
iPhone4,1 = iPhone 4S
iPhone5,{1..3} = iPhone 5
iPhone5,{4..6} = iPhone 5C
iPhone6,* = iPhone 5S
iPod1,1 = iPod touch 1G
iPod2,1 = iPod touch 2G
iPod3,1 = iPod touch 3G
iPod4,1 = iPod touch 4G
iPod5,1 = iPod touch 5G
iPad1,1 = iPad 1G
iPad2,{1..4} = iPad 2
iPad2,{5..7} = iPad mini 1G
iPad3,{1..3} = iPad 3G
iPad3,{4..6} = iPad 4G
iPad4,{1..3} = iPad Air
iPad4,{4..6} = iPad mini 2G
On Nov 26, 2013, at 16:57, Roland King r...@rols.org wrote:
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 physical screen size you
would need an API point which either returns it directly, or returns the
pixel density in px/cm.
Anyway I went with the suggestion of an earlier poster and scaled up so it
was nearly as big as I wanted on the mini, and bigger than I really wanted
on the iPad, both using the same pointsize for the elements. And that's not
a bad compromise (in fact on the larger iPad the bigger test cards are very
clear and you don't really notice they are .. a bit huge). Problem solved,
one interface for either of the two sizes of iPad, and the iPhone was never
a problem.
I still would like that API point, I shall file a bug which will be duped.
On 26 Nov, 2013, at 4:18 pm, Jacky.Seraph Mu jackyser...@gmail.com wrote:
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 r...@rols.org
Is there yet a supported way of finding out the actual screen size (or
equivalently pixel density) on an iOS screen?
I have an app, uses autolayout, works fine on iPhone (one storyboard),
iPad (another storyboard) and mostly looks fine between iPad and iPad
mini. One screen however has a number of test 'cards' on it. On the phone
one card == one screen looks great. On a full-sized iPad, about 6 to a
page is clear, on a mini however 6 is not ideal and 4, or 3, looks much
better and is much clearer to test. That's one of the fairly rare cases
where one size doesn't fit all and knowing the actual screen dimensions
would make a better user experience.
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?
___
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/jackyseraph%40gmail.com
This email sent to jackyser...@gmail.com
___
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/xcvista%40me.com
This email sent to xcvi...@me.com
___
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:
Re: iOS screen physical size (or px density)
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
Re: iOS screen physical size (or px density)
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
Re: iOS screen physical size (or px density)
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
Re: iOS screen physical size (or px density)
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
Re: iOS screen physical size (or px density)
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 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
Re: iOS screen physical size (or px density)
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 argument applies to adding more / less content on iPad mini screen because of its physical dimensions. It’s a bad UX choice IMHO) :: marcelo.alves ___ 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
Re: iOS screen physical size (or px density)
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 bad UX choice IMHO) :: marcelo.alves Precisely. ___ 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
Re: iOS screen physical size (or px density)
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 and HDMI screen (using uname(2) and I2C respectively) but AirPlay can be trickier. Building such an database is impossible for screens over Airplay or HDMI, let alone display settings on the device may also affect the results. Hence, if your only concern is the main display, read uname(2) and use a small database of Apple devices. On Nov 26, 2013, at 22:36, Igor Elland igor.ell...@me.com wrote: 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 bad UX choice IMHO) :: marcelo.alves Precisely. ___ 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/xcvista%40me.com This email sent to xcvi...@me.com ___ 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
Re: iOS screen physical size (or px density)
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
Re: iOS screen physical size (or px density)
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
Re: iOS screen physical size (or px density)
On 26 Nov 2013, at 15:51, Roland King r...@rols.org 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 following the HIG specifications for size really helps here, when there’s nothing smaller than the smallest suggested sizes, they do translate fairly well. But if you have really busy UIs with smaller controls than the HIG recommends, than designing “for the Mini first” should help prevent and elucidate such cases. ___ 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
Re: Best way to put a fixed view in a UITableViewController scene?
On 26 Nov 2013, at 12:53 AM, Rick Mann rm...@latencyzero.com wrote: On Nov 25, 2013, at 21:11 , Luther Baker lutherba...@gmail.com 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 right click on the UITableView, I see both the delegate and datasource outlets. I can click them and easily drag/connect to the parent First View Controller. Do you mean something else? You can't put a UITableViewController into a Container View, and link from the UITVC back to the containing view controller. Sure you can (if I understand you correctly). The containment segue has an identifier, and you can capture the .destinationViewController in -prepareForSegue:sender:. Bear in mind that no other NIB loading has been done at that point. — F ___ 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
Re: iOS screen physical size (or px density)
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, their screen resolutions, current sizes and device IDS, guessing what might happen in the future and putting lots of ifs in my layout. But that wasn't my question and it isn't how I work, I didn't ask for a hack, I asked if there was yet an Apple-supported API to deduce this information programatically, directly, and there still isn't. So I did the next best thing and gave up the idea of having fixed-world-sized views between ipad and ipad mini and found one screen size which works ok for either; then filed the bug report. On 26 Nov, 2013, at 10:54 pm, Maxthon Chan xcvi...@me.com wrote: 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
Re: iOS screen physical size (or px density)
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 from now on. On 26 Nov, 2013, at 10:54 pm, Igor Elland igor.ell...@me.com wrote: On 26 Nov 2013, at 15:51, Roland King r...@rols.org 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 following the HIG specifications for size really helps here, when there’s nothing smaller than the smallest suggested sizes, they do translate fairly well. But if you have really busy UIs with smaller controls than the HIG recommends, than designing “for the Mini first” should help prevent and elucidate such cases. ___ 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
NSTask and 10.9
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]; [task launch]; [task release]; where rootScriptPath is from: NSString *rootScriptPath = [[NSBundle mainBundle] pathForResource:@DeleteHiddenRoot ofType:nil]; and DeleteHiddenRoot is: #!/bin/sh rm -dfR $1.f* rm -dfR $1._* rm -dfR $1.DS* rm -dfR $1.S* chmod ugo+rw $1.Trashes rm -dfR $1.T* finally, rootpath is from: NSArray *pathComponents = [[NSString stringWithCString:(const char*)dir encoding:NSASCIIStringEncoding] pathComponents]; NSString *mediapath = [pathComponents objectAtIndex:0]; mediapath = [mediapath stringByAppendingPathComponent:[pathComponents objectAtIndex:1]]; mediapath = [mediapath stringByAppendingPathComponent:[pathComponents objectAtIndex:2]]; NSString *rootpath = [mediapath stringByAppendingString:@/]; This works just fine up to and including 10.8.5 BUT throws an exception at [task launch] on 10.9 Google reveals nothing about this … at first I thought that sh was not available but in Terminal on 10.9 entering !#/bin/sh puts you into sh any help is much appreciated … ! -koko ___ 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
Re: NSTask and 10.9
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 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
Re: NSTask and 10.9
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 what paths you need to use…
I hope that this helps.
On 26 Nov 2013, at 15:47, koko k...@highrolls.net wrote:
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];
[task launch];
[task release];
where rootScriptPath is from:
NSString *rootScriptPath = [[NSBundle mainBundle]
pathForResource:@DeleteHiddenRoot ofType:nil];
and DeleteHiddenRoot is:
#!/bin/sh
rm -dfR $1.f*
rm -dfR $1._*
rm -dfR $1.DS*
rm -dfR $1.S*
chmod ugo+rw $1.Trashes
rm -dfR $1.T*
finally, rootpath is from:
NSArray *pathComponents = [[NSString stringWithCString:(const char*)dir
encoding:NSASCIIStringEncoding] pathComponents];
NSString *mediapath = [pathComponents objectAtIndex:0];
mediapath = [mediapath stringByAppendingPathComponent:[pathComponents
objectAtIndex:1]];
mediapath = [mediapath stringByAppendingPathComponent:[pathComponents
objectAtIndex:2]];
NSString *rootpath = [mediapath stringByAppendingString:@/];
This works just fine up to and including 10.8.5 BUT throws an exception at
[task launch] on 10.9
Google reveals nothing about this … at first I thought that sh was not
available but in Terminal on 10.9 entering !#/bin/sh puts you into sh
any help is much appreciated … !
-koko
___
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/45rpmlists%40googlemail.com
This email sent to 45rpmli...@googlemail.com
___
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
Re: Best way to put a fixed view in a UITableViewController scene?
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 work out of the box, not hard to roll your own and get the behavior you are looking for ... Even still with Xibs. On Nov 26, 2013, at 12:53 AM, Rick Mann rm...@latencyzero.com wrote: On Nov 25, 2013, at 21:11 , Luther Baker lutherba...@gmail.com 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 right click on the UITableView, I see both the delegate and datasource outlets. I can click them and easily drag/connect to the parent First View Controller. Do you mean something else? You can't put a UITableViewController into a Container View, and link from the UITVC back to the containing view controller. -- Rick ___ 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
Re: NSTask and 10.9
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 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
Re: NSTask and 10.9
On Nov 26, 2013, at 9:42 AM, koko k...@highrolls.net 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...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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
Re: iOS screen physical size (or px density)
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 not be shabby as well. On Nov 26, 2013, at 23:13, Roland King r...@rols.org wrote: 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 from now on. On 26 Nov, 2013, at 10:54 pm, Igor Elland igor.ell...@me.com wrote: On 26 Nov 2013, at 15:51, Roland King r...@rols.org 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 following the HIG specifications for size really helps here, when there’s nothing smaller than the smallest suggested sizes, they do translate fairly well. But if you have really busy UIs with smaller controls than the HIG recommends, than designing “for the Mini first” should help prevent and elucidate such cases. ___ 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
Re: NSTask and 10.9
So:
NSFileManager *fileMgr = [NSFileManager defaultManager];
NSArray *contents = [fileMgr contentsOfDirectoryAtPath:path
error:nil];
for (NSString *item in contents)
{
if ([item rangeOfString:wildcard].location !=NSNotFound)
{
[fileMgr removeItemAtPath:item error:NULL];
}
}
Please note that I haven't tested this - I've just pulled it out of my, erm,
head. This is just the approach that I'd take. Change path and wildcard
as appropriate.
On 26 Nov 2013, at 16:42, koko k...@highrolls.net 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.
___
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
Re: NSTask and 10.9
On Tue, Nov 26, 2013, at 09:37 AM, koko wrote: On Nov 26, 2013, at 10:26 AM, Kyle Sluder k...@ksluder.com wrote: Error 2 is ENOENT. The path you passed to -setLaunchPath: does not exist. Not possible as [task setLaunchPath:rootScriptPath]; where rootScriptPath is NSString *rootScriptPath = [[NSBundle mainBundle] pathForResource:@DeleteHiddenRoot ofType:nil]; Well, you never actually proved that this method returns something other than nil. But we'll assume you verified that even passing a hardcoded, known-good path to -setLaunchPath: causes the same symptoms. so do you know if Mavericks disallows NSTask access to the App Bundle? Perhaps. Starting in Mavericks, all the binaries within a signed bundle must be themselves signed before the bundle is signed, because their signatures form part of the bundle's designated requirement. I've only seen this discussed in the context of frameworks, but I would not be surprised if it also applied to scripts or other tasks launched via posix_spawn. For more details, see Craig Hockenberry's blog post: http://furbo.org/2013/10/17/code-signing-and-mavericks/ --Kyle Sluder ___ 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
Re: iOS screen physical size (or px density)
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 holding it further from their face. If you find that your iPad UI is too small on the iPad mini, then it was likely too small to begin with on the iPad. Jeff Kelley slauncha...@gmail.com | @SlaunchaMan https://twitter.com/SlaunchaMan | jeffkelley.org On Tue, Nov 26, 2013 at 12:00 PM, Maxthon Chan xcvi...@me.com wrote: 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 not be shabby as well. On Nov 26, 2013, at 23:13, Roland King r...@rols.org wrote: 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 from now on. On 26 Nov, 2013, at 10:54 pm, Igor Elland igor.ell...@me.com wrote: On 26 Nov 2013, at 15:51, Roland King r...@rols.org 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 following the HIG specifications for size really helps here, when there’s nothing smaller than the smallest suggested sizes, they do translate fairly well. But if you have really busy UIs with smaller controls than the HIG recommends, than designing “for the Mini first” should help prevent and elucidate such cases. ___ 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/slaunchaman%40gmail.com This email sent to slauncha...@gmail.com ___ 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
Re: Best way to put a fixed view in a UITableViewController scene?
On Nov 26, 2013, at 08:12 , Luther Baker lutherba...@gmail.com 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 static table content. You can wire it up in IB, but the table calls the data source methods and fails (UITVC implements the necessary methods to handle the static content). If you try to subclass UITVC, then it complains its view is not a UITableView (obviously). -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
Re: Best way to put a fixed view in a UITableViewController scene?
On Nov 25, 2013, at 21:16 , Luther Baker lutherba...@gmail.com 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 view I want to display is fairly tightly coupled to the state of the content of the table view. Second, in one place I have a push segue from a dynamic table view cell to this container. In that push, I want to set a model object on the embedded TVC, but I can't get at it (the container's childViewControllers is empty at the time of the push). All this because UITVC insists that its table view also be its root view, and there's no good reason for that. -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
Re: Best way to put a fixed view in a UITableViewController scene?
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 rm...@latencyzero.com wrote: On Nov 26, 2013, at 08:12 , Luther Baker lutherba...@gmail.com 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 static table content. You can wire it up in IB, but the table calls the data source methods and fails (UITVC implements the necessary methods to handle the static content). If you try to subclass UITVC, then it complains its view is not a UITableView (obviously). -- Rick ___ 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/rmann%40latencyzero.com This email sent to rm...@latencyzero.com -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
Re: Best way to put a fixed view in a UITableViewController scene?
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 (or stupid), but what about the tableHeaderView (or tableFooterView) property? (not the same as section headers) :: marcelo.alves ___ 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
Re: Best way to put a fixed view in a UITableViewController scene?
On Nov 26, 2013, at 19:18 , Marcelo Alves marcelo.al...@me.com 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: Message signed with OpenPGP using GPGMail ___ 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
Re: NSTask and 10.9
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 -waitUntilExit in the wrong order. I have no idea what it could mean to wait for the task to exit before it's launched. I wouldn't be surprised if that's what is throwing the exception. That said, I agree with the suggestion to delete the files from within the parent process rather than launching a script to do it. Regards, Ken ___ 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
Re: Best way to put a fixed view in a UITableViewController scene?
On Nov 26, 2013, at 6:06 PM, Rick Mann rm...@latencyzero.com 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 there that relies on UITVC.view pointing at the table view. You'll notice they did not repeat that mistake with UICollectionViewController. But even if they were to divorce the view and tableView properties, you shouldn’t muck with the internal layout of a view controller’s view hierarchy unless explicitly documented. Perhaps your best bet at this point is to ditch UITVC and static cells altogether, and file a set of radars asking for 1) static cell support for non-UITVC-controlled table views, 2) separation of UITVC.view from UITVC.tableView, 3) explicit permission override -[UITVC viewWillLayoutSubviews] to do custom layout without calling super. My mantra is that storyboards are the bindings of iOS. They get you 80% of the way to covering 80% of use cases; but if you fall off the golden path, you get to backtrack all the way. --Kyle Sluder ___ 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
Can't remove autoresizing constraints?
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 is that IB/iOS create autoresizing mask constraints on the table view. By the time I can setTranlates to NO, it's too late, the constraints are made. So I try to remove them in -viewDidLoad, by calling: [self.tableView.superview removeConstraints: self.tableView.constraints] But this has no effect. I tried calling it on self.tableView, as well. The constraints are still there after removal. I'm doing this in an attempt to programmatically create constraints for both the table view and the banner view that live within a programmatically-created UIView. I need the constraints because the banner slides in from the top when shown, and slides out when hidden (this part is currently working with the view container solution I have). -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
