Suchergebnisse

Zitat von SteveJ: „Schade. Einfache Lösung: Passwort-Authorisierung reicht in der Annahme, dass sich für Deine App nicht so viele Leute interessieren. Wenn sich genug Leute interessieren hast du auch das Geld dir jemanden zu leisten der sich damit auskennt:“ Die App ist für eine Firma. Die App wird auch von einigen Leuten benutzt. Und ich muss mich halt darum kümmern. Zitat von Amin Negm-Awad: „Klar, du willst mit der App Geld verdienen. Die Arbeit steckt aber im Server. Wenn den jetzt jeder nut…

Zitat von gritsch: „Zitat von Erebos1988: „Wenn ich mit dem Key die relevanten Daten Verschlüssel und der Angreifer den Key nicht hat, kann er mit der Kommunikation zwischen Client und Server ja nichts anfangen. Der Server kennt den key ebenfalls und entschlüsselt die Daten dann wieder.“ und wie soll der server den key kennen wenn du ihn auf dem gerät jedesmal neu erzeugst? außerdem kann jeder angreifer alles lesen ob dus verschlüsseltst oder nicht. weil ich schau mir einfach die daten an bevor …

Wenn ich mit dem Key die relevanten Daten Verschlüssel und der Angreifer den Key nicht hat, kann er mit der Kommunikation zwischen Client und Server ja nichts anfangen. Der Server kennt den key ebenfalls und entschlüsselt die Daten dann wieder.

Den key wollte ich ja zum verschlüsseln nutzen, denn hätte man mit der AZitat von gritsch: „Zitat von Erebos1988: „Das würde ja bedeuten, dass ich Hardcode ein Passwort hinterlegen / generieren müsste. Dieses könnte man aber herausbekommen, wenn die app dekompiliert wird.“ so ist es. das bekommt man immer raus. vor allem wenn du die infos an einen server schicken willst.“ Den Key wollte ich ja zum verschlüsseln nutzen, dann hätte man mit der Anfrage nichts anfangen können.

Das würde ja bedeuten, dass ich Hardcode ein Passwort hinterlegen / generieren müsste. Dieses könnte man aber herausbekommen, wenn die app dekompiliert wird.

Hallo ist es möglich zur Laufzeit einen eindeutigen Key auszulesen? Der Key darf natürlich nicht im Code hinterlegt sein oder von einer anderen App erzeugt werden können. Ich dachte an das normale Codesigning aber das kann man scheinbar nicht zur Laufzeit auslesen. Ich möchte den Key nutzen um sicherzustellen, dass nur meine App meinen Webservice nutzen kann.

Naja man kann auch Glück haben. Wenns nicht durch kommt, kann man es ja abändern. Scheint auch davon abhängig zu sein, wer eine App veröffentlicht. Programmierer xy oder Firma xy.

Problem ist das man nicht ohne weiteres einen Screenshot des Homescreens machen kann, so weit ich weiß. Es ist aber möglich screenshots in deiner Anwendung zu machen. Hilft dir aber nicht weiter. Du könntest vorher einen screenshot von einem standard homescreen anfertigen und dieses für einen fake nutzen.

Hallo, Coredata ist ja nicht ohne weiteres Threadsafe. Laut Doku soll jeder Thread seinen eigenen ManagedObjectContext haben. So weit so gut. Jetzt will man diese ja auch zusammenführen. Wenn ich jetzt den neuen ObjectContext im Thread erstelle, gibt es die Möglichkeit eine Notification bei Änderungen des Contexts zu senden: Quellcode (16 Zeilen) Somit bekommt der mainContext die Änderungen also mit. Aber der Context im Thread bekommt doch keine Änderungen am MainContext mit oder? Müsst sowas eq…

Sollten Timer denn immer im Mainthread laufen? Im Hintergrundprozess sind bei mir ebenfalls Timer, die müsste ich ja dann auch auf dem Mainthread laufen lassen. Da werde ich dann doch an einigen Stellen umbauen müssen aber was muss das muss.

Zitat von Amin Negm-Awad: „Wenn der Timer rechenintensive Sachen auslöst, sollte das Ausgelöste in einem Thread, besser in einer Operation-Queue oder einem dispatch_async() stehen, nicht aber der Timer.“ So wie es momentan ist, laufen die rechenintensiven Sachen ja in einem extra Thread. Weil der Timer ja auch nicht im Mainthread läuft. Ich werde jetzt aber eh versuchen das mit einer Operation-Queue zu machen. Das Konzept sieht genau nach dem aus, was ich brauche/nutze

Dann werde ich mich damit mal beschäftigen. Danke.

Zitat von macmoonshine: „Aber wie gesagt: Meiner Meinung nach kannst Du auf den Thread verzichten und nur mir dem Timer arbeiten.“ Wie meinst du das, nur dem Timer nutzen? Der löst ja rechenintensive sachen aus, die würden dann doch die GUI zum stoppen bringen. Das hatte ich glaube in meiner ersten version so Oder meinst du der Timer soll dann jeweils eine Operation ausführen die ja im Hintergrund abläuft?

Mainthread und Backgroundthread arbeiten an einer Stelle auch mit der selben Instanz. Der Backgroundthread schreibend, der Mainthread lesend.

Das Objekt ist gar nicht mal so wichtig, wenn es null ist dann arbeitet der Mainthread mit dem weiter was er an Daten hat. Und wenn zB. gerade eine Animation ausgeführt, dürfte die ja nicht einfrieren. Ist ja absolut getrennt voneinander. Oder habe ich da einen denkfehler?

Also ich greife dort auf jeden Fall auf das objekt zu. Aber auch wenn das objekt nicht mehr existieren würde, würde doch nicht alles einfrieren? Der Backgroundthread manipuliert quasi das Model etc. und der Mainthread ist halt für die GUI. Würde nur der backgroundthread einfrieren, wodurch auch immer, müsste der Mainthread ja trotzdem weiterlaufen. Durch die ganzen Logs die ich in meinem Programm habe kann ich auch relativ genau sehen, das das ganze Programm einfach stehen bleibt.

Versteh nicht warum der Code jetzt nicht mehr formatiert ist. War er vor dem kopieren noch. Als ich mit NSThreads anfing, wusste ich noch nichts von NSOperations. Können die denn auch einen Timer aufnehmen? Dieser Backgroundthread läuft nämlich dauerhaft. Bieten NSOperations sonstige Vorteile? Wenn ja, werde ich mich da mal einlesen. Ich habe gerade gelesen, das es durch die NSNotifications auch zu deadlocks kommen kann. Könnte also auch sein, das die notification der Fehler ist.

Meine App friert manchmal ein und ich bin mir nicht ganz sicher warum. Ich denke es hat was mit performSelectorOnMainThread:withObject:waitUntilDone: zu tun Und zwar habe ich einen Backgroundthread. Diesen erzeuge ich so: Quellcode (17 Zeilen) Wenn der backgroundthread seine arbeite erledigt hat, sendet er folgendes: Quellcode (1 Zeile) Dies kommt dann hier an: Quellcode (4 Zeilen) In den meisten Fällen wird doSomething aufgerufen aber manchmal hängt sich das Programm auch einfach auf. Ich bekom…

Ich habe den Fehler gefunden. Wie schon vermutet wird das NSMuttableArray = String gesetzt und zwar in der Parserklasse mit: [self.mediaInfo setValue:self.currentElementValue forKey:elementName]; Ganz großes Danke an MCDan!

Zitat von MCDan: „NSLog(@"Attachments:%@",[[parser mediaInfo] Attachments]);“ Dies erzeugt keine Exception, die Ausgabe ist aber leer, sprich: Attachments: