TheElements - UIWindow ???

[blinker13]

Hey,

ich habe eine für viele vielleicht unwichtige Frage weil es ja den IB dafür gibt aber mich lässt das einfach nicht in Ruhe!!!

In den Sample Codes von Apple gibt es eines das heißt "TheElements" und in eben diesem gibt es keine .nib in der ein UIWindow Outlet kreiert wird.
Ich möchte jetzt gerne wissen wie das funktioniert das das UIWindow angezeigt wird.

Ich habe das nachgebaut aber bei mir will das UIWindow einfach nicht auftauchen.

Ich habe die MainWindow.xib gelöscht,
in der info.plist den untersten Eintrag gelöscht (Main Nib file base name)
und ein UIWindow erstelt mit einem gelben Hintergrund ....

aber nichts!

AppDelegate.h --->

#import <UIKit/UIKit.h>

@interface WindowTestAppDelegate : NSObject <UIApplicationDelegate>
{
UIWindow *portraitWindow;
}

@property (nonatomic, retain) UIWindow *portraitWindow;

@end


AppDelegate.m --->

#import "WindowTestAppDelegate.h"

@implementation WindowTestAppDelegate

@synthesize portraitWindow;

/*************************************************************************/
- (void) configureUI
{


UIWindow *localPortraitWindow;
localPortraitWindow = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
self.portraitWindow = localPortraitWindow;
[localPortraitWindow release];
[portraitWindow setBackgroundColor:[UIColor greenColor]];
[portraitWindow makeKeyAndVisible];
}

/*************************************************************************/
- (void) applicationDidFinishLaunching: (UIApplication *)application
{
[self configureUI];
}

/*************************************************************************/
- (void) dealloc
{
[portraitWindow release];
[super dealloc];
}

@end


Bitte helft mir das zu verstehen!!! Danke!!!

 

[Peter Maurer]

Wenn Du keine MainWindow.nib-Datei mehr hast, woher weiss Deine UIApplication-Instanz dann, wer ihr Delegate ist?

Du musst dann wohl ueber eine UIApplication-Subklasse gehen (Info.plist: NSPrincipalClass); aber ich weiss ehrlich gesagt nicht sicher, ob iPhone-Programme ueberhaupt auf eine NSPrincipalClass-Angabe hoeren. Probier's aus.

 

[Amin Negm-Awad]

-setDelegate: Aber schön ist anders.

Eine Subklasse von NSApplication sollte man dafür auf keinem Fall machen.

 

[Peter Maurer]

UIApplication, in dem Fall; und jetzt frage ich mal aus Neugier: Wo -- ausser in einer UIApplication-Subklasse -- will man -setDelegate: sinnvollerweise aufrufen, wenn man keine NIB-Dateien hat? Direkt in main.m? (Das wuerde mir zumindest auch nicht besser gefallen.)

 

[Amin Negm-Awad]

UIApplication, in dem Fall; und jetzt frage ich mal aus Neugier: Wo -- ausser in einer UIApplication-Subklasse -- will man -setDelegate: sinnvollerweise aufrufen, wenn man keine NIB-Dateien hat? Direkt in main.m? (Das wuerde mir zumindest auch nicht besser gefallen.)

Wo fängt denn NSApplication (oder UIApplication) an zu arbeiten? Mit [NSApplication sharedApplication] – ja, ohne den Rückgabewert zu beachten, einfach nur so, um mal anzufangen. Irgendwo steht das sogar mal als Sourcecode. Frag mich aber bitte nicht wo.

Wenn man einen Anfang haben will, muss man sich eben einen Singleton instanzieren. Das dürfte sogar in main() gehen.

Aber nein, sinnvoll ist das nicht. Und Subclassing ist auch nicht sinnvoll. Es ist ja kein Versehen von Apple, dass NSApplication einen Nib gleich lädt. Man sollte das unbedingt so machen.

 

[Jamsven]

"nib" stands for "nib is better"

Ich glaub dem TE ging es sich nicht drum auf nib Dateien zu verzichten und sämtliche Code conventions zu brechen , sondern die Funktionsweise dahinter zu verstehen.

 

[Amin Negm-Awad]

"nib" stands for "nib is better"

Ich glaub dem TE ging es sich nicht drum auf nib Dateien zu verzichten und sämtliche Code conventions zu brechen , sondern die Funktionsweise dahinter zu verstehen.

Kann schon gut sein. Dann sei gesagt (und zusammengefasst)

Es wird eine Singleton-Instanz von NSApplication erzeugt. Wenn ich mich recht entsinne, erzeugt die auch gleich einen Autorelease-Pool. Dann wird der Nib geladen und die Verbindungen erstellt. IIRC wird dann in die Event-Loop eingetreten.

Will man das also selbst machen, müsste es reichen, in einer eigenen Singleton-Instanz des Delegates gleich zu beginn [NSApplication sharedApplication] zu machen. Dan kann man sich auch glech als Delegate setzen.

Ich habe das jedoch noch nie probiert und werde das auf absehbare Zeit auch nicht tun.

 

[ifthenelse]

Die Singleton-Instanz von UIApplication wird durch UIApplicationMain( ) generiert, typischerweise in main.m
Die Namen der Principal Class und der (Application) Delegate Class können dort als String angegeben werden, müssen aber nicht... (dann Default-"Wert" bzw. Eintrag in info.plist)
Die Funktion ist dokumentiert in den UIKit Function References:
http://developer.apple.com/iphone/l...tFunctionReference/UIKitFunctionReference.pdf
(Zugriff benötigt einen iPhone Developer Account)

 

[Jamsven]

Was ist denn eine Principal Class?

 

[Amin Negm-Awad]

Was ist denn eine Principal Class?

In einem Bundle existiert eine Klasse, die nach dem Laden des Bundles instantert werden soll. Die Klasse nennt man die Principal-Class. Du kannst sie beim Target im Info-Window unter Properties setzen. (Siehe einfach im Buch Seite 682).

Üblicherweise ist das dann NSApplication (UIApplication). Wenn man eine eigene Subklase erzeugt hat, muss man ja irgendwo auch sagen, dass diese Subklasse instantiert werden soll. Daher muss man die entsprechende Einstellung bei der Principal-Class machen.

 

[Amin Negm-Awad]

Die Singleton-Instanz von UIApplication wird durch UIApplicationMain( ) generiert, typischerweise in main.m Die Namen der Principal Class und der (Application) Delegate Class können dort als String angegeben werden, müssen aber nicht... (dann Default-"Wert" bzw. Eintrag in info.plist)
Die Funktion ist dokumentiert in den UIKit Function References:
http://developer.apple.com/iphone/l...tFunctionReference/UIKitFunctionReference.pdf
(Zugriff benötigt einen iPhone Developer Account)

Sorry, hatte dich falsch verstanden.

 

[Peter Maurer]

Wo fängt denn NSApplication (oder UIApplication) an zu arbeiten? Mit [NSApplication sharedApplication] – ja, ohne den Rückgabewert zu beachten, einfach nur so, um mal anzufangen.

Deshalb ja der Gedanke, sich genau da mit einer Subklasse einzuhaengen. Das ist auch politisch in Ordnung, die UIApplication-Dokumentation erwaehnt naemlich ausdruecklich die Moeglichkeit des Einsatzes einer Subklasse, wie ich gerade entdeckt hab' -- wenn auch in anderem Zusammenhang. Dann wird eine NSPrincipalClass-Angabe wohl funktionieren.

Ob man also [UIApplication sharedApplication] anderswo, z.B. direkt in main(), extra aufruft, um dann den Delegate festzulegen, oder das in +sharedApplication mit dem Rueckgabewert der Superklassen-Implementierung macht, das halte ich deshalb wie so oft bei Cocoa fuer eine Geschmackssache -- solange man die eine oder andere Taktik nicht eh aus anderen Gruenden anwendet.

In main() musste ich mich noch nie einklinken; aber unter Mac OS X z.B. sind Hot Keys und bestimmte Arten des Umgangs mit Rechts-Klick-Mausereignissen immer ein schoener Grund fuer NSApplication-Subklassen. Auf dem iPhone gibt es wahrscheinlich aehnlich eindeutige Faelle.

... gerade allerdings faellt mir auf: Ich hatte geschrieben, es muesse dann wohl ueber eine UIApplication-Subklasse gehen. Das war falsch, ich geb's ja zu.

Aber wie dem auch sei:

Es ist ja kein Versehen von Apple, dass NSApplication einen Nib gleich lädt. Man sollte das unbedingt so machen.

Komplett einverstanden!

Mich macht's eben manchmal Spass, darueber nachzudenken, was unter bestimmten Voraussetzungen (hier: komm' ohne NIB aus) die subjektiv eleganteste Taktik waere. Und die eigentliche Frage hatte ich ja schon beantwortet (NIB weg -> kein Delegate -> kein Aufruf der Eigenbau-Fensterzeigemethode); also kann man ja mal ein bisschen spinnen.

Fuer ein einfaches iPhone-Programm ist das alles allerdings unnoetig kompliziert, und deshalb natuerlich nicht ernsthaft als bessere Alternative zu empfehlen -- da kann ich nur nochmals ausdruecklich zustimmen.

 

[Amin Negm-Awad]

Politisch korrekt ist die Entscheidung eher nicht, da es um einen anderen Zweck geht. Das ist maßgeblich für das einzusetzende Pattern. Du kannst ja nicht aus dem Pattern für Fall A schließen, dass dies ein Pattern für Fall B ist. (Ja, im Event-Dispatching herumzufummeln ist der Grund schlechthin.)

Bei Cocoa* sollte man wirklich nur zum Subclassing greifen, wenn das so gedacht ist oder es gar nicht anders geht. Du handelst dir White-Boxing ein.

 

[blinker13]

Also ich hab längerem Suchen eine Lösung gefunden.


int main(int argc, char *argv[]) {

NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
int retVal = UIApplicationMain(argc, argv, nil, @"PollenflugAppDelegate");
[pool release];
return retVal;
}

Vorher steht an der Stelle mit @"PollenflugAppDelegate" "nil" was soviel bedeutet wie das als ertes die nib geladen wird die in der info.plist als mainScreen deklariert ist.


Danke euch allen für eure Hilfe

 

[Amin Negm-Awad]

Wolltest du nicht gerade keinen Nib laden?