Load a nib on iPad
by Brian Szatkowski · in iTorque 2D · 09/06/2010 (7:28 pm) · 6 replies
Hi All;
I'm trying to get a nib to load in my app on the iPad (not the mainWindow.xib) and have had no success.
Before I come back with gobs of code showing what I have not accomplished, perhaps someone can shed some light as to if they have achieved this, what I would call, relatively simple task.
I have updated the imagePicker code posted by Ecliptic Pulling up an Image Picker with iTGB to replace deprecated calls so it will work with iOS 3.0 and up. This is working fine on the iPhone 2g and iPhone 4 but does not on the iPad. Of course, Apple had to use a different approach for the iPad, requiring that an imagePicker be launched within a UIPopoverController. Whatever. I made those modifications and believe them to be correct. However, I really have no way of knowing since I cannot, for the life of me, get the nib to load (the part I would consider easy).
Any thoughts/experiences?
Thank you
I'm trying to get a nib to load in my app on the iPad (not the mainWindow.xib) and have had no success.
Before I come back with gobs of code showing what I have not accomplished, perhaps someone can shed some light as to if they have achieved this, what I would call, relatively simple task.
I have updated the imagePicker code posted by Ecliptic Pulling up an Image Picker with iTGB to replace deprecated calls so it will work with iOS 3.0 and up. This is working fine on the iPhone 2g and iPhone 4 but does not on the iPad. Of course, Apple had to use a different approach for the iPad, requiring that an imagePicker be launched within a UIPopoverController. Whatever. I made those modifications and believe them to be correct. However, I really have no way of knowing since I cannot, for the life of me, get the nib to load (the part I would consider easy).
Any thoughts/experiences?
Thank you
About the author
#2
Thanks for your feedback.
Yes, I created a new iPad nib in Interface Builder (named completely different than the iPhone one). In fact, I went so far as to create a new XCode project with the sole purpose of launching the Image Picker via a UIPopoverController, and this worked flawlessly.
However, trying to use that same nib in my current iT2D-ified XCode project results in the nib failing to load.
09/06/2010 (11:12 pm)
Hi Marc;Thanks for your feedback.
Yes, I created a new iPad nib in Interface Builder (named completely different than the iPhone one). In fact, I went so far as to create a new XCode project with the sole purpose of launching the Image Picker via a UIPopoverController, and this worked flawlessly.
However, trying to use that same nib in my current iT2D-ified XCode project results in the nib failing to load.
#3
potentially its configured to be an iphone only project
Guess you did the required rework so it works as ipad + iphone application too (not just one resolution)
09/06/2010 (11:42 pm)
check if the xcode project is set to iphone + ipad in the active target settings.potentially its configured to be an iphone only project
Guess you did the required rework so it works as ipad + iphone application too (not just one resolution)
#4
Yes, I did extensive reworking of the code base to ensure it truly works as a Universal app. I can detect iPhone (2g-3gs), iPad, and iPhone 4 (to include the forthcoming iPod with Retina displays--I knew they were coming soon!), set the device to its native (full screen) resolution, and handle all six device orientation settings (Dean Parker and I did a lot of work on that front, as you can see from the Resources he posted).
This and the lack of having access to the app's Documents directory are the only two things holding me up from finishing this app.
09/06/2010 (11:53 pm)
Yeah, that was one of my first thoughts. I do have the Targeted Device Family set to iPhone/iPad.Yes, I did extensive reworking of the code base to ensure it truly works as a Universal app. I can detect iPhone (2g-3gs), iPad, and iPhone 4 (to include the forthcoming iPod with Retina displays--I knew they were coming soon!), set the device to its native (full screen) resolution, and handle all six device orientation settings (Dean Parker and I did a lot of work on that front, as you can see from the Resources he posted).
This and the lack of having access to the app's Documents directory are the only two things holding me up from finishing this app.
#5
Already Instant Action seems to think thats they way to go and I could hardly hate them more for it as it has brought the damned mess with hardcoded values.
Apple recommends (and I guess somewhen might enforce it), that you check for presence of functionality you want to use.
In case of a game that basically means screen size and "ipad or not" (which comes from the OS version as .2 = ipad, rest iphone and that will likely not change anytime soon)
Screen Size:
Just create a window and use its bounds.
Will tell you what screen size you have
Decide if you want to add an optimized mode in addition that renders at half size and scales up (usefull for 4th generation and ipad and the way the automagic for 4th gen devices works with old apps)
In addition, check for if it is ipad or not.
Those two things are all you need and should do.
Not generation based testing as that won't get you anywhere beside the land of frustration year after year.
I guess you might want to work with it for a longer time :)
as for the documents directory: There the root of Torque are hurting or the lack of iphone focus and interest on "i"Torque2D.
Its all based around its resource system.
Problem is that getting around the resource system is not that trivial due to the blocks you still need to use so what you want to do is likely add the possibility of absolute path specification over relative only (and make the resource system check for abslute vs relative either basing on the path or by offering distinct functions or overloads witha bool parameter where the default version does what it does now) or just kill relative and get expandPath to really expand it to absolute
btw: consider using cache over documents where suitable.
documents: get backed up with itunes backup
cache: does not get backed up (-> saves lots of time especially for data they can redownload / changes regularily anyway).
I personally use documents primarily for game save and other really persistent data on iphone projects and cache for the rest
09/07/2010 (1:08 am)
detection of device is exactly what rule number one on the guides from apple tells you not to do.Already Instant Action seems to think thats they way to go and I could hardly hate them more for it as it has brought the damned mess with hardcoded values.
Apple recommends (and I guess somewhen might enforce it), that you check for presence of functionality you want to use.
In case of a game that basically means screen size and "ipad or not" (which comes from the OS version as .2 = ipad, rest iphone and that will likely not change anytime soon)
Screen Size:
Just create a window and use its bounds.
Will tell you what screen size you have
Decide if you want to add an optimized mode in addition that renders at half size and scales up (usefull for 4th generation and ipad and the way the automagic for 4th gen devices works with old apps)
In addition, check for if it is ipad or not.
Those two things are all you need and should do.
Not generation based testing as that won't get you anywhere beside the land of frustration year after year.
I guess you might want to work with it for a longer time :)
as for the documents directory: There the root of Torque are hurting or the lack of iphone focus and interest on "i"Torque2D.
Its all based around its resource system.
Problem is that getting around the resource system is not that trivial due to the blocks you still need to use so what you want to do is likely add the possibility of absolute path specification over relative only (and make the resource system check for abslute vs relative either basing on the path or by offering distinct functions or overloads witha bool parameter where the default version does what it does now) or just kill relative and get expandPath to really expand it to absolute
btw: consider using cache over documents where suitable.
documents: get backed up with itunes backup
cache: does not get backed up (-> saves lots of time especially for data they can redownload / changes regularily anyway).
I personally use documents primarily for game save and other really persistent data on iphone projects and cache for the rest
#6
This was a really great rundown and there are some very important points that anyone should follow.
While Apple does recommend testing for the availability of desired functionality as opposed to testing for device or iOS version, this was specifically because people were submitting garbage code like "If this is an iPod, then I know the device does not have a camera, so therefore do not allow these camera functions I wrote to run." Now, this will fail with the new Retina versions of the iPod (which now have cameras) and also the iPad (which does not).
While your screen bounds solution will work, so does the one I have (which uses nothing but Apple-approved code).
I simply use UI_USER_INTERFACE_IDIOM() to determine if the device is an iPad, If not, then I do a UIScreen (with a respondsToSelector) call to scale to determine if it's a Retina display. These results give me all of the info I need to set resolution/scene/features/nibs/etc.
This "resource system" is where I am currently focusing my efforts (and frustration).
I agree that cache generally would be the best place to store/retrieve data (including images), However, in my app, the user is intentionally storing a cropped image for use at any date in the future. Without placing this in the Documents directory, as you illustrated, it will not get backed up. I certainly wouldn't want a user complaining to me that some botched iOS upgrade wiped their data and I tell them there is nothing I can do.
Thanks again for all of your valuable insight.
09/07/2010 (1:35 am)
Hi Marc;This was a really great rundown and there are some very important points that anyone should follow.
While Apple does recommend testing for the availability of desired functionality as opposed to testing for device or iOS version, this was specifically because people were submitting garbage code like "If this is an iPod, then I know the device does not have a camera, so therefore do not allow these camera functions I wrote to run." Now, this will fail with the new Retina versions of the iPod (which now have cameras) and also the iPad (which does not).
While your screen bounds solution will work, so does the one I have (which uses nothing but Apple-approved code).
I simply use UI_USER_INTERFACE_IDIOM() to determine if the device is an iPad, If not, then I do a UIScreen (with a respondsToSelector) call to scale to determine if it's a Retina display. These results give me all of the info I need to set resolution/scene/features/nibs/etc.
This "resource system" is where I am currently focusing my efforts (and frustration).
I agree that cache generally would be the best place to store/retrieve data (including images), However, in my app, the user is intentionally storing a cropped image for use at any date in the future. Without placing this in the Documents directory, as you illustrated, it will not get backed up. I certainly wouldn't want a user complaining to me that some botched iOS upgrade wiped their data and I tell them there is nothing I can do.
Thanks again for all of your valuable insight.
Torque 3D Owner Marc Dreamora Schaerer
Gayasoft
there are steps to convert it, cause iphone nib won't work with ipad and vice versa.
Also there are things that just don't exist in the same form on the ipad (image picker is among the top differences as that uses the ipad capabilities and works pretty differently on the ipad from my experience in attempting to modal overlay it)