If I have a universal app (runs on both iPhone & iPad), how do I account for UI layout differences in code if the UI differs between the devices?
If I am using a XIB, I can simply load a different XIB depending on the device and use the same code. Correct?
If I am creating my UI programmatically, though, how should this be handled? Is there a better way than if/elsing my way through the code and looking at the device type? I understand it's doable this way, it just doesn't seem very elegant.
if (isiPhone)
{
UIView *myCommonView = [[UIView alloc] initWithFrame:CGRectMake(0.0, 0.0, 150.0, 50.0)];
myCommonView.backgroundColor = [UIColor colorWithPatternImage:iPhoneSpecificImage];
// bunch of other conditional code
}
else
{
UIView *myCommonView = [[UIView alloc] initWithFrame:CGRectMake(0.0, 0.0, 250.0, 150.0)];
myCommonView.backgroundColor = [UIColor colorWithPatternImage:iPadSpecificImage];
// bunch of other conditional code
}
A much better alternative to using loads of if/else statements is to have multiple app delegates. An easy way to do this is to create an AppDelegate_iPhone & AppDelegate_iPad and respectively bind them (in IB) to the different XIBs that get loaded on launch. Now you have a way to programmatically add different items to each delegate.
This also can lead to an issue where you want to share UI elements between the delegates. In this case, you can create shared views that are used by both delegates (just import the view controller in both cases).
The code should structurally look something like this.
Unfortunately, programmaticaly if/elsing is the only way to do this. But when you think of it it's not that bad. Apple allows you to produce 2 different apps from the same code for 2 different devices.
Related
I'll try to keep it short. I want to create a 3D FPS game, just for myself, that can run on multiple platforms, but I figured that to keep it simple, perhaps it is best to start off with something that is exclusively for macOS. I opted for Objective-C because
(a) Window Application projects in Xcode can only be coded either in Obj-C or Swift (since we are dealing with Cocoa API) and
(b) Obj-C is closer to old-school then Swift.
But before I learn to draw/render 2D-shapes on the window's canvas by writing code, I have to learn to invoke an application window with its properties set to my liking. I've spent hours doing research and experimenting with chunks of code. This is what I've tried: I open with
#import <Cocoa/Cocoa.h>
int main(int argc, const char * argv[]) {
#autoreleasepool {
Then I go with ...
1)
NSWindow *window = [[[NSApplication sharedApplication] windows] firstObject];
NSRect frame = [window frame];
frame.origin.x = 100;
frame.origin.y = 200;
frame.size.width = 100;
frame.size.height = 500;
[window setFrame: frame display: YES];
... and close with ...
NSApplicationMain(argc, argv); // runs the win display function.
}
return (0) ;
}
But no visible changes. Nothing really gets reset. So instead of (1) I tried ...
2)
NSWindow *window = [[[NSApplication sharedApplication] windows] firstObject];
NSPoint newOrigin;
newOrigin.x = 400;
newOrigin.y = 100;
[window setFrameOrigin : newOrigin];
Still nothing. Then instead of (2) I tried:
3)
NSWindowController* controller = [[NSWindowController alloc]
initWithWindowNibName:#"MainMenu"];
[controller showWindow:nil];
Great. Now it's spitting out something I don't understand, especially since I'm new to Obj-C:
2020-02-08 21:53:49.782197-0800
tryout_macApp2[14333:939233] [Nib Loading] Failed
to connect (delegate) outlet from
(NSWindowController) to (AppDelegate): missing
setter or instance variable
I remember dicing around with an ApplicationDelegate, with CGSizeMake(), etc., but it just made the experience really inundating and frustrating. Nothing happened. Then there are NSView, NSViewController, and other classes, which is really mindboggling and begs the question: why are there so many classes when all I want to do is override the preset origin of the window and the dimensions preset by the MainMenu.xib file? (By the way, this project is derived from a Window Application project provided by Xcode.)
I really can't think of anything else to add to give you the entire picture of my predicament, so if you feel that something is missing, please chime in.
[Edit:] Moving forward to phase 2 of my project here: How do I paint/draw/render a dot or color a pixel on the canvas of my window with only a few lines in Obj-C on Mac OS X using Xcode?.
The short answer is that main() is too early to be trying to do this. Instead, implement -applicationDidFinishLaunching: on your app delegate class, and do it there. Leave main() as it was originally created by Xcode's template.
After that, I would say to obtain the window (if there's only going to be one main one), it's better to add an outlet to your app delegate and then, in the NIB, connect that outlet to the window. Then, you can use that outlet whenever you want to refer to the window.
Also, make sure that Visible at Launch is disabled for the window in the NIB. That's so you configure it as you want before showing it.
For a more complex app, it's probably better to not put a window into the Main Menu NIB. Instead, make a separate NIB for the window. Then, load it using a window controller object and ask that for its window.
I love Objective-C but also feel your pain, it has this testy ability to frustrate you endlessly.
I have not really developed a game but let me try and point you in the right direction. I think you need a UIViewController.
Now each UIViewController has a built in UIView that sort of represents the visible portion of it. You can use this or add a UIView and use that, whichever depends on your implementation. For now I'd suggest add a separate UIView and use that rather. Once you're comfortable you can then move the implementation to the UIViewController's view if you need to.
Anyhow, for now, create a UIView subclass, say MyGame or something, as for now all your code will end up there.
To do all of the above is not easy, especially if its the first time. If you can follow some tutorial it will be great. Even if the tutorial just adds a button, you can use it and replace the button with your view.
Anyhow, now that you've got that running and the view you've added shows up in green or some other neon colour just to verify that you can indeed change its properties, you're good to go.
Now you start. In MyGame, implement the
-(void)drawRect:(CGRect)rect
message, grab the context through
UIGraphicsGetCurrentContext
and start drawing lines and stuff on it, basically the stuff I understand you are interested in doing. You can also, through the same context, change the origin of what you are doing.
Hope this helps.
In ios 7 and before, I was updating the bounds of presentedViewController.view.superview to custom the size of presented view controller, but it seems this would not be the case in ios 8 any more. Since there is no superview can be set on the view controller(return nil when you try to call it in debugger).
Any suggestions how to update the presented view controller's size? This would be used for the custom presentation transition.
I guess the following is easier and it works in iOS 8:
self.myViewController.modalPresentationStyle = UIModalPresentationFormSheet;
self.myViewController.modalTransitionStyle = UIModalTransitionStyleCrossDissolve;
//This will be the size you want
self.myViewController.preferredContentSize = CGSizeMake(822, 549);
[self presentViewController:self.myViewController animated:YES completion:nil];
In case anyone runs into this later, here is how I solve it.
Subclass the UIPresentationController and return the frame in frameOfPresentedViewInContainerView. Feed this into the transitioningDelegate that you create for the presentedViewController.
Or, you may set the final frame for the presentedView in the animateTransition:, which belongs to the animator object you created for transitioningDelegate. However, this is the old iOS 7 way of doing it. Since Apple introduce UIPresentationController, any size/frame changes should be done there instead, which is the previous method I mentioned.
Here are some extra information that may not be directly related to solving the problem.
For those of you who never got your hands on the apple view controller transition api, just like me before, here are the steps.
Create YourTransitioningDelegate, which conforms UIViewControllerTransitioningDelegate. In here, generally three things need to be set, PresentationController, PresentedAnimationController, DismissedAnimationController.
Create YourTransitionAnimator, which conforms UIViewControllerAnimatedTransitioning. Here, two functions need to be override, transitionDuration and animateTransition(This is where all the animation happens, adding/removing and animating the presentedView. Make you call completeTransition on transitionContext to end the animation).
Subclass UIPresentationController. Depends on each individual needs, you may do a ton of things here. I just added a dimmingView and changed the frame of presentedViewController.
Finally, hook things up before presenting the view controller, which is changing the modalPresentationStyle to be custom and setting the transitioning delegate.
Things I found really helpful, two 2014 WWDC videos("View controllers advancements" and "A look inside presentation controllers") and the sample project from Apple(LookInside-photoEditingApp).
Instead of subclassing you can use the preferredContentSize property
- (void)viewDidLoad {
[super viewDidLoad];
self.preferredContentSize = CGSizeMake((self.view.frame.size.width / 100) * 65, (self.view.frame.size.height / 100) * 65);
}
Apologies if this is a silly question, but I've done some googling and searched SO and haven't found anyone asking this exact question.
I have been doing iOS development for some time now, but I am completely new to the Interface Builder. What I want to know is this: is there any way to just create ONE .xib file and then use it for both iPhone and iPad in a Universal application?
It seems silly to me to have to create them separately; why do twice the work laying something out more than once in Interface Builder when I could do it once (with minor adjustments for screen size) in code?
Please let me know if I'm missing/misunderstanding something here. Like I said, I'm a complete Interface Builder newbie :)
EDIT: I have submitted non-interface-builder games to the App Store in the past where the iPhone and iPad versions were identical, so I'm not concerned with making the game look/feel different on each device. I intend for them to look exactly the same, aside from some slight positioning changes due to the difference in aspect ratio.
If you know what the resulting view would look like, based on autoresizing, you can indeed use only one .xib. May come in handy if the view is just some sort of a shared component that autoresizes as you want it to. However, if you need the view to look way different on iPad than on iPhone, just use two .xibs. It’s possible then to load the appropriate one as needed, for example in instance initializer, like this controller’s -init:
- (id)init
{
if ([UIDevice currentDevice].userInterfaceIdiom == UIUserInterfaceIdiomPad)
{
self = [super initWithNibName:#"YourNibForPad" bundle:nil];
}
else
{
self = [super initWithNibName:#"YourNibForPhone" bundle:nil];
}
if (self) { /* initialize other ivars */ }
return self;
}
The main reason that XIBs are separate files is because Apple feel that UIs designed for iPhones/iPod touches and iPads should be tailored to each respectively. This is echoed in their their iOS App Programming Guide, which says the following:
For views, the main modification is to redesign your view layouts to support the larger screen. Simply scaling existing views may work but often does not yield the best results. Your new interface should make use of the available space and take advantage of new interface elements where appropriate. Doing so is more likely to result in an interface that feels more natural to the user—and not just an iPhone app on a larger screen.
Whilst it can take time to maintain two XIBs for what is effectively one UI, I feel it is more straightforward than using one XIB and then having to connect up most of your UI elements in order to move them around programmatically when that XIB loads. After all, with two XIBs at least you can see what each UI looks like, and then make visual changes easily.
As an aside, don't forget iOS 5's Storyboards (read about them here), which make managing a view/view controller hierarchy much simpler.
Try to name them
MyCell.xib and MyCell ~ ipad.xib
then:
[self.tableView registerNib: #"MyCell" forCellReuseIdentifier: #"MyUniqueIdentifier"];
If your using IB, you need to create 2 separate xib files for iPhone and iPad. You need a separate iPad xib to make your app comply with the Apple iPad UI guidelines.
Is it possible to simply duplicate ipad display to TV out (assuming both have same resolution)?
Code like this doesnt seem to work (it is a pretty naive implementation)
int i=0;
for (UIScreen *screen in [UIScreen screens])
{
if(i>0)
{
UIWindow* extWindow = [[UIWindow alloc]init];
extWindow.screen =screen;
[extWindow addSubview:viewController.view];
[extWindow makeKeyAndVisible];
}
i++;
}
[window addSubview:viewController.view];
[window makeKeyAndVisible];
Code like this doesnt seem to work (it
is a pretty naive implementation)
This code looks like a mishmash. I haven't used external screens before, but your inner if block is creating anonymous UIWindow objects, assigning a property, and then leaking them at the end of the block (no release) -- and that definitely won't do what you intend.
You should consult the iPad Programming Guide, specifically, Support for External Displays and Projectors, which summarizes how your code should be written.
If you need this for a demo presentation, then there are few apps that will duplicate the screen for you while running your app like TVOut, TVOut2, Screenspltr. However there is a catch, these apps are not approved by Apple therefore are not in the app store, in order to install them you'll need to jailbreak it and it comes with the involved risks. However for a quick dome it is probably the best solution.
In my application I needed something like a particle system so I did the following:
While the application initializes I load a UIImage
laserImage = [UIImage imageNamed:#"laser.png"];
UIImage *laserImage is declared in the Interface of my Controller. Now every time I need a new particle this code makes one:
// add new Laserimage
UIImageView *newLaser = [[UIImageView alloc] initWithImage:laserImage];
[newLaser setTag:[model.lasers count]-9];
[newLaser setBounds:CGRectMake(0, 0, 17, 1)];
[newLaser setOpaque:YES];
[self.view addSubview:newLaser];
[newLaser release];
Please notice that the images are only 17px * 1px small and model.lasers is a internal array to do all the calculating seperated from graphical output. So in my main drawing loop I set all the UIImageView's positions to the calculated positions in my model.lasers array:
for (int i = 0; i < [model.lasers count]; i++) {
[[self.view viewWithTag:i+10] setCenter:[[model.lasers objectAtIndex:i] pos]];
}
I incremented the tags by 10 because the default is 0 and I don't want to move all the views with the default tag.
So the animation looks fine with about 10 - 20 images but really gets slow when working with about 60 images. So my question is: Is there any way to optimize this without starting over in OpenGl ES?
As jeff7 and FenderMostro said, you're using the high-level API (UIKit), and you'd have better performance using the lower APIs, either CoreAnimation or OpenGL. (cocos2d is built on top of OpenGL)
Your best option would be to use CALayers instead of UIImageViews, get a CGImageRef from your UIImage and set it as the contents for these layers.
Also, you might want to keep a pool of CALayers and reuse them by hiding/showing as necessary. 60 CALayers of 17*1 pixels is not much, I've been doing it with hundreds of them without needing extra optimization.
This way, the images will already be decompressed and available in video memory. When using UIKit, everything goes through the CPU, not to mention the creation of UIViews which are pretty heavy objects.
Seems like you're trying to code a game by using the UIKit API, which is not really very suitable for this kind of purpose. You are expending the device's resources whenever you allocate a UIView, which incurs slowdowns because object creation is costly. You might be able to obtain the performance you want by dropping to CoreAnimation though, which is really good at drawing hundreds of images in a limited time frame, although it would still be much better if you used OpenGL or an engine like Cocos2d.
The UIImageView is made to display single OR multiple images. So, instead of creating every time a UIImageView, you should consider creating a new image and add it to the UIImageView instead.
See here.
I'd recommend starting over using OpenGL ES, there is an excellent framework called cocos2d for iPhone that can make this type of programming very easy and fast. From a quick look at your code, you're lasers can be remodeled as CCSprite which is an easy way to move images around a scene among many other things.