I know it's very vague and is asking a lot but does anyone know how to convert the standard iOS starter project from iPhone to iPad (both is best)? Or does anyone know where I can download one. I am a new iOS developer and am trying to start learning with Parse.
I am referring to this project https://www.parse.com/downloads/ios/parse-starter-project/latest
P.S. Just because this question isn't perfect doesn't mean you have to go and down vote and flag it for removal I don't have a lot of points already no need to lose even more :)
Not being able to see this sample project, it's hard to say for certain what it will take.
At bare minimum go into your project summary, and select "Universal" for the device support.
Above and beyond that, it just depends on what the app is and how it's structured. For NIBs, you will want a NIB for iPhone and one for iPad. I find it easy to abstract this away so that I can simplify my view loading:
MyController *myController = [[MyController alloc] initWithView:#"MyControllerView" bundle:nil];
Then in a category, I'd define initWithView similar to:
#implementation UIViewController (Universal)
-(id) initWithView:(NSString *)view bundle:(NSBundle *)nibBundle{
bool isIpad = UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad;
NSString *nibName = [NSString stringWithFormat:#"%#_%#", view, (isIpad ? #"iPad" : #"iPhone")];
return [self initWithNibName:nibName bundle:nibBundle];
}
#end
But, that's just one aspect of supporting both devices. In reality the subject is rather specific to the app you're working on. Things like OS support (e.g., am I only targeting iOS 6 or higher) play a factor in things.
I have solved it now, if anyone needs the files email me turboecreations#iCloud.com I would upload them but I dont want my MediaFire and other accounts to be removed if I run into copyright issues.
Related
I am learning objective C and could use some pointers (pun intended). I have a background in Java. I just finished the book 'Programming with Objective C'. I was trying to use drawWithRect to draw some text onscreen but cannot get this piece of sample code to work.
#import <Cocoa/Cocoa.h>
#import <AppKit/NSStringDrawing.h>
//#import <UIKit/UIKit.h> //this is invalid
//#import <UIKit/UIColor.h> //this is invalid
#import "NSString+Draw.h"
NSDictionary *attributes = #{
NSForegroundColorAttributeName:[UIColor blueColor]
};
[#"Hello" drawWithRect:CGRectMake(20, 20, 50, 50)
options:0 attributes:attributes context:nil];
It doesn't seem to be in the Frameworks folders in my XCode project. I had looked on apple developer site but was swamped by unrelated information.
How do I get this UIKit? Is this an addon? btw why are some imports using quotes and others angle brackets? are they interchangeable?
I don't have a good big picture of the frameworks. What are the key frameworks?
Is there a web based API documentation like Javadocs?
Still at it.
Is there an equivalent of UIKit/UIColor etc for OSX?
- I found it, AppKit/NSColor
Ok After a bit of exploration I got this but it still doesn't write onscreen.
#import <Cocoa/Cocoa.h>
#import <AppKit/NSStringDrawing.h>
#import <AppKit/NSColor.h>
#import "NSString+Draw.h"
#implementation NSString (Draw)
- (void) drawString:(NSString *) myString{
NSDictionary *attributes = #{
NSForegroundColorAttributeName:[NSColor blueColor]
};
[#"Hello" drawInRect:CGRectMake(20, 20, 50, 50) withAttributes:attributes];
}
It looks like you've created a project targeting OSX. UIKit is a framework that is included with iOS only. Create an iOS project to use that framework.
UIKit is the big framework for iOS, and includes things like UIColor (or anything else with a UI prefix).
Docs are online, and can also be found in Xcode in the 'Help' tab
To draw anything on the screen, you need something called a Graphics Context. The Graphics Context gives you an area to draw in and manipulate. Apple does a good job of explaining it in their documentation here. Further research through the Apple documentation turns up a specific section for drawing text (NSString in particular). An excerpt below from the NSString Drawing documentation:
The Application Kit adds three methods to the NSString class to support drawing string objects directly in an NSView instance: drawAtPoint:withAttributes:, drawInRect:withAttributes:, and sizeWithAttributes:.
There are three things you may want to check in order to ensure everything is / will be drawn properly:
You must have an active NSView to draw on. Check that there is an active NSView to draw on.
You may need to add more parameters to your attributes dictionary. I don't see any required keys, but it might be a good idea to add a font parameter and a background color parameter.
Does the text actually fit in the specified bounds? Maybe specify a larger CGRect (at least for testing)?
If you're absolutely frustrated with drawing NSString using AppKit's methods, try the Core Text framework:
Core Text is an advanced, low-level technology for laying out text and handling fonts. The Core Text API, introduced in Mac OS X v10.5 and iOS 3.2, is accessible from all OS X and iOS environments.
Information on Frameworks and general SDK questions:
When you download Xcode, you're also downloading the Development SDK and related documentation too. The Development SDK is mainly comprised of Frameworks (from Apple). A Framework is a huge compiled code library with visible-header files. So, you can't see the implementations, but you can see the headers.
When importing a framework (doesn't matter if it's from Apple or not), use brackets (or a module if you have it enabled in the build settings). When importing files (not frameworks) then just use quotes.
There are a LOT of frameworks for both iOS and OS X. I can't list them all here, but I can tell you the key ones. Here's a link to the iOS developer documentation, including the frameworks. The big four on iOS are Foundation, UIKit, CoreGraphics, and (sometimes) QuartzCore. When you click on your project in the Xcode file navigator, you should see the project settings and a list of frameworks included. Click the plus button to see all Apple frameworks you can add. Most of them are related to system services (ex. GameCenter framework is GameKit, and Passbook framework is PassKit).
Yes! The Apple Developer Documentation is available both online and offline (installed with Xcode). Online documentation can usually be found through googling, but here's a link. It's also in the Xcode Help menu / documentation menu. You can also option-click on any piece of code you want to learn more about.
The equivalent to UIKit (an iOS only framework) for OS X is AppKit. Most of the classes are the same names, just with an NSA prefix instead of a UI prefix. For example, on OS X you'd need NSColor instead of UIColor.
Apart fro needed to use UIKit and an iOS project, it's also beer to just import the top level header, rather than the individual ones.
So just
#import <UIKit/UIKit.h>
Or, if on Xcode 5
#import UIKit;
To do things visually you need a Graphics Context to draw in.
Objective-C does not provide one.
An operating system does through a window server.
AppKit on OS X provides this through NSWindow.
UIKit on iOS provides this with a single implicit window.
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.
I am trying to make a simple app from a tutorial that does not have a viewController at all. All the code is in the AppDelegate. I am on xcode 4.2 and I am getting this error:
Applications are expected to have a root view controller at the end of application launch
I'm not sure how to deal with this. There are some blogs out there with fixes but none of them are working for me and I really would like to understand what is going on here. And, how to fix it.
I do have a view that contains some buttons and labels. But I have no "ViewController". The files contained in my project are: AppDelegate.h, AppDelegate.m, and Window.xib only. There is no ViewController.h, ViewController.m
** edit **
I ended up making the app from a 'view based application' instead and just moving all the logic from the app delegate to the view controller. So, I didn't really solve the problem per se. The app works now though. Thanks for the help
It's not possible to have an iOS app that doesn't have a view controller. You can always create a trivial view controller, i.e.,
[[UIWindow alloc] initWithFrame:UIScreen.mainScreen.bounds].rootViewController =
[[[UIViewController alloc] init] autorelease];
It sounds like you're looking at an old tutorial. UIWindow got a rooViewController property in iOS4. I believe it became required in iOS5 to help keep controller hierarchies and view hierarchies in sync with the addition of custom container controllers (and to fix a corner case where replacing the "root controller" of a UIWindow could stop orientation changes from propagating). There was a WWDC presentation in 2011 that explained this in some detail. I think it was Session 102, Implementing UIViewController Containment.
At then end of the day, there's no good reason not to have a root view controller. Apple wants to be able to assume it's there in their APIs going forward. If the tutorial you're looking at doesn't account for that, it's broken.
While I agree that there may be workarounds, another question to address is: why do you want an app without a view? Even if it's designed to run in the background and present no visual interface, at least make a simple view showing the application name and version, a largeish icon and perhaps a status. This kind of idle screen uses very little system resources, especially when the app is backgrounded, but improves the overall experience of the app.
If you set your deployment target to 4.3 and run on the iPhone 4.3 simulator, you won't get the warning.
To install the iOS 4.3 simulator, go to Xcode > Preferences > Downloads.
Despite searching all over the place, I can't find the answer to my question. So let's see how good y'all are. :)
I'm working on an app that uses an NSPopover which is only available in 10.7 Lion but I want the app to compile for 10.5 and higher. I'm using a preprocessor directive to wrap the related popover code which seems to do the trick... However, the last piece I'm still getting errors on is the .zib in Interface Builder. How do I go about cleaning up the errors shown in the Issues Navigator stating "Class Unavailable: NSPopover on Mac OS X versions prior to 10.7"?
#ifdef __MAC_OS_X_VERSION_MAX_ALLOWED
#if __MAC_OS_X_VERSION_MAX_ALLOWED >= 1070
#property (assign) IBOutlet NSPopover *popover;
}
#endif
#endif
The above works in xxx.h and xxx.m's, but how do I get around the .xib errors?
Despite the error (Red), it builds successfully. However am I wrong to expect the 10.7 features (popover) to work in 10.7 because they don't... What am I missing here?
You shouldn't use preprocessors for this but check for availability at runtime using NSClassFromString(). The preprocessor runs at compile time, thus it won't detect what system the app is being run on.
Create three nibs, one for each of 10.5, 10.6 and 10.7 and load the one you need (or do it in code), but pick which one at run time, not compile time, e.g.
MyVC *vc = nil;
if (NSClassFromString(#"NSPopover"))
{
vc = [NSViewController initWithNibName:#"MyVC-Lion" bundle:nil];
}
else if (/* check for 10.6+ only features */)
{
vc = [NSViewController initWithNibName:#"MyVC-SL" bundle:nil];
}
else
{
vc = [NSViewController initWithNibName:#"MyVC" bundle:nil];
}
// ...
Not a real answer to your question, apologies, but 2 possible workarounds: isn't it possible to create 2 versions of your xib, and depending on the target, compile on or the other? This would be a bit more work to maintain, but if your UI is pretty stable, this should be the easiest way.
Or you could add your "10.7 specific" UI component(s) programmatically instead of using the IB. If you just have one or a few popovers, it shouldn't be to difficult to do, and the proprocessor guards would work fine.
I have an app where the user can make in-app purchases. The problem is that the binaries for iPad and iPhone are going to be different. Is there any way to share the in-app purchases between both apps so that the user doesn't have to pay twice for the same thing?
I think there is no way to do this, but maybe there is any suggestion.
My best regards,
Antonio.
You cannot share in-app-purchases between different apps. The solution is to create a universal app which serves both hardware platforms.
It may be confusing in the beginning, but you do not have to maintain two codebases on the long run. So make your code conditional, like ...
check if you are on an iPad
BOOL isIPad = (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad);
load your .xib files conditonally
NSString *conditionalXibName = isIPad ? #"MyXibFileName-iPadVersion" : #"MyXibFileName-iPhoneVersion";
UIViewController *myViewController = [[UIViewController alloc] initWithNibName:conditionalXibName bundle:nil];