Skip to content
Browse files

Fixed some typos, added some notes. I should stop while I'm ahead.

git-svn-id: svn://dev.iconfactory.net/Projects/Software/UIKit/trunk@5171 d3437ac4-8b1b-0410-be28-b75ab53cb89f
  • Loading branch information...
1 parent f79de00 commit 9cd73b0a22174f78cbc1952538f63aaa9c5cd406 @BigZaphod committed
Showing with 4 additions and 2 deletions.
  1. +4 −2 README.md
View
6 README.md
@@ -20,9 +20,9 @@ The UIKit port in Chameleon starts at a very low level and attempts to go so far
The interface between AppKit's NSViews and NSWindows and Chameleon's UIWindow and UIViews occurs at the "screen" level. UIKitView is an NSView which you add to your NSView hierarchy in whatever way you want. The UIKitView hosts a UIScreen instance which is home to UIKit's interface elements.
-Each UIWindow belongs to a UIScreen, and UIViews must exist on UIWindows. This should mostly work the same as you've come to expect on iOS. An important thing to note is that Mac applications often have more than one window. If you use more than one UIKitView in your app, be aware that this means your application how has more than one UIScreen and as a result some methods such as [UIScreen mainScreen] may suddenly do unexpected things. When porting Twitterrific from iOS, this was one source of unexpected bugs as a few things were making assumptions about there only being a single, main screen since that is normal on current iOS devices.
+Each UIWindow belongs to a UIScreen, and UIViews must exist on UIWindows. This should mostly work the same as you've come to expect on iOS. An important thing to note is that Mac applications often have more than one window. If you use more than one UIKitView in your app, be aware that this means your application now has more than one UIScreen and as a result some methods such as [UIScreen mainScreen] may suddenly do unexpected things. When porting Twitterrific from iOS, this was one source of unexpected bugs as a few things were making assumptions about there only being a single, main screen since that is normal on current iOS devices.
-Once a UIKitView exists and there's a UIScreen available to work with, your code can proceed to build a UIWindow and UIViews on top of it and be largely unaware that it is actually running on OSX instead of iOS. For those cases where you need to customize some UI, `UIUserInterfaceIdiomDesktop` has been added so that your code can differentiate between running on a pad, phone, or desktop. To keep code cross platform, the following is a good way to structure things so that Apple's UIKit doesn't encounter the unknown `UIUserInterfaceIdiomDesktop` symbol when compiling for iOS:
+Once a UIKitView exists and there's a UIScreen available to work with, your code can proceed to build a UIWindow and UIViews on top of it and be largely unaware that it is actually running on OSX instead of iOS. For those cases where you need to customize some UI, `UIUserInterfaceIdiomDesktop` has been added so that your code can differentiate between running on a pad, phone, or desktop in a consistent way. To keep code cross platform, the following is a good way to structure things so that Apple's UIKit doesn't encounter the unknown `UIUserInterfaceIdiomDesktop` symbol when compiling for iOS:
if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPhone) {
// iPhone
@@ -32,6 +32,8 @@ Once a UIKitView exists and there's a UIScreen available to work with, your code
// Mac
}
+(You can always use #ifdef or other compile-time approaches for platform differentiation, too - especially since a Mac app built with Chameleon doesn't need to adapt to multiple UI idioms at runtime the way a universal iOS app does. I just find it nice to have a similar pattern for all 3 idioms - but maybe that's just me.)
+
You can usually just create an instance of your iOS app's UIApplicationDelegate object and then pass it into UIKitView's helper method `-launchApplicationWithDelegate:afterDelay:` which will emulate the startup process of an iOS app (it will even attempt to show a Default.png if a delay is given). You might perform this step in your NSApplicationDelegate object's `-applicationDidFinishLaunching:` method. It is not necessary to use UIKitView's helper method to "launch" your app, but it can be a good way to get started.
Generally the interfaces to the classes are the same as Apple's documented interfaces. Some objects have additional methods that are useful for OS X and are defined in `(ClassName)AppKitIntegration.h` headers which are not included by the standard `UIKit.h` header. To easily include all AppKit extensions into your code, import `UIKit/AppKitIntegration.h` when compiling on OS X. There are also a couple of non-standard UI classes defined such as UIKey and UIViewAdapter that I designed out of necessity. (Keyboard handling in particular is a weak spot of Apple's current UIKit and so I developed my own rough API in place of anything "official" being documented by Apple.)

0 comments on commit 9cd73b0

Please sign in to comment.
Something went wrong with that request. Please try again.