Speicherwarnung + performselector = unsicher?

yunharla

Mitglied
Thread Starter
Mitglied seit
05.04.2011
Beiträge
65
Moinsen,
dieses mal hats mich wirklich echt total aufm falschen Fuß erwischt. Und zwar gibt es
in meiner App eine View die nicht mehr auf performselector reagiert wenn sie im
Falle einer Speicherwarnung gelöscht wird. Besagte View verhält sich aber in diesen
Situation nicht anders als die anderen gelöschten Views (welche aber funktionieren).
jemand vieleicht eine idee wie man herausfinden könnte warum das nun so ist?
 

below

Aktives Mitglied
Mitglied seit
15.03.2004
Beiträge
13.564
Was bedeutet denn "reagiert nicht mehr auf verformSelector"? Wie sieht dieses nicht-reagieren aus?

Alex
 

yunharla

Mitglied
Thread Starter
Mitglied seit
05.04.2011
Beiträge
65
Also der Debugger zeigt an das performselector ausgeführt wird und zwar eindeutig
für das richtige Objekt. Im Objekt (also dieser View) wird jedoch keine Methode
aufgerufen.
 

little_pixel

Aktives Mitglied
Mitglied seit
06.06.2006
Beiträge
4.629
Kannst Du das bitte in Code zeigen?

Viele Grüße
 
  • Gefällt mir
Reaktionen: below und _ebm_

yunharla

Mitglied
Thread Starter
Mitglied seit
05.04.2011
Beiträge
65
sicher doch ...

hier der "Einstiegspunkt" in der View
Code:
                DataServiceClient *dataClient = ((oowql_clientAppDelegate*)[UIApplication sharedApplication].delegate).dataServiceData;
		[dataClient Execute:req withCallback:@selector(retrieveEntityMetaComplete:) andCallbackRecipient:self];	
}
jetzt wird das Objekt mit Daten gefüttert (was ohne Probleme geschieht) bis die
App diesen Punkt hier erreicht:

Code:
   	if([self.CallbackRecipient respondsToSelector:self.CallbackAction])
    {
        NSLog(@"%@",self.CallbackRecipient);
        
        [self.CallbackRecipient performSelector:self.CallbackAction withObject:response withObject:self.Tag];
    }
nun müsste ja eigentlich Folgendes ausgeführt werden (genau wie bei den anderen
Views), was jedoch nicht geschieht wenn diese View zu irgendeinen Zeitpunkt
durch eine Speicherwarnung gelöscht wird.

Code:
- (void)retrieveEntityMetaComplete:(Response*)response {
	if ([response isKindOfClass:[ExceptionResponse class]]) {
Und jetzt das lustige:

ohne den Smalltalk-BS, also in normalen C funktioniert es :)
 

little_pixel

Aktives Mitglied
Mitglied seit
06.06.2006
Beiträge
4.629
Code:
oowql_clientAppDelegate
Klassen schreibt man groß.

Code:
CallbackAction
Variablen und Co schreibt man klein.

Code:
[dataClient Execute:req
Methoden schreibt man auch klein.

Code:
withObject:self.Tag]
Wenn "Tag" das ist was ich denke, dann ist es kein Objekt.

self.CallbackAction
Wir wissen nicht was dadrin steht.

Bitte sei nicht böse, aber das sieht alles schlecht aus.

Den wichtigsten Tipp, Grundlagen, werden gleich die anderen nochmals sagen.

Viele Grüße

PS:
Es empfiehlt sich sehr Views, Controller usw. voneinander zu trennen. Warum sollte Dein View irgend ein empfangenes Zeugs verwalten?
 

_ebm_

Aktives Mitglied
Mitglied seit
19.01.2008
Beiträge
2.079
ohne den Smalltalk-BS
Bitte keine Kraftausdrücke. Du willst mit Objective-C programmieren, dann lebe mit der Syntax.

Ich kann nur schwer anhand des gezeigten Codes erkennen warum die Applikation stirbt. Auf jedem Fall solltest du little_pixel's Ratschläge beachten.
 

below

Aktives Mitglied
Mitglied seit
15.03.2004
Beiträge
13.564
Der Selector retrieveEntityMetaComplete: kann da gar nicht ausgeführt werden :Oldno:

Muss aber ins Meeting

Alex
 

yunharla

Mitglied
Thread Starter
Mitglied seit
05.04.2011
Beiträge
65
yeeee Problem ist gefixt... anscheinend hat ein Kollege da ein paar Sachen für den
Client aus den C# und Java Versionen nicht richtig übernommen wodurch der
"Scroll"-Request zu früh behandelt wurde. :p

@little_pixel
Joa das wollte ich vorm einchecken sowieso noch überarbeiten, aber trotzdem danke
für den Hinweis. ^^
 

below

Aktives Mitglied
Mitglied seit
15.03.2004
Beiträge
13.564
yeeee Problem ist gefixt... anscheinend hat ein Kollege da ein paar Sachen für den
Client aus den C# und Java Versionen nicht richtig übernommen wodurch der
"Scroll"-Request zu früh behandelt wurde. :p
Anscheinend... das sieht schon sehr merkwürdig aus, was ihr da macht :suspect:

Alex
 

yunharla

Mitglied
Thread Starter
Mitglied seit
05.04.2011
Beiträge
65
Anscheinend... das sieht schon sehr merkwürdig aus, was ihr da macht :suspect:

Alex
Kann ich genauso wenig nachvollziehen wie die letzte Aussage von Pixel. Es sei
denn du meinst damit das nicht der "normale" Weg für Callbacks gegangen wurde.
(welcher ja wie schon von mir gesagt auch funktioniert hat)
 

below

Aktives Mitglied
Mitglied seit
15.03.2004
Beiträge
13.564
Auf den zweiten Blick .. ich habe mich von "Callback" verwirren lassen. Ihr implementiert ja einfach einen Delegate, und macht ihr ganz richtig :jaja:

Alex
 

below

Aktives Mitglied
Mitglied seit
15.03.2004
Beiträge
13.564
Nachtrag: Ihr solltet vielleicht hier ein Delegate Protocol verwenden. Dann kannst Du sehr schön sowas machen

if ([foo respondsToSelector:@selector(bar:withFoobar:)])
[foo bar:a withFoobar:y];

Alex
 

yunharla

Mitglied
Thread Starter
Mitglied seit
05.04.2011
Beiträge
65
Nachtrag: Ihr solltet vielleicht hier ein Delegate Protocol verwenden. Dann kannst Du sehr schön sowas machen

if ([foo respondsToSelector:@selector(bar:withFoobar:)])
[foo bar:a withFoobar:y];

Alex
Hatte ich auch schon einmal drüber nachgedacht es zumindest in die Library einzubauen...
 
Oben