Offenbar jemand vom Fach, danke fuer die ausfuehrliche Erklaerung 
ZitatOriginal geschrieben von tw2
Das Problem dabei ist, dass es so kurz läuft, dass z.B. Anwendungen wie GPS-Tracking im Hintergrund weiterhin nicht möglich sind. Nämlich nur 15 Sekunden in 30 Minuten, wenn das Gerät nicht am Strom hängt.
Weisst du, wie genau diese 15 Sekunden definiert sind? Ist das tatsaechlich genutzte CPU-Zeit, oder zaehlt's auch wenn die App zwar aktiv ist, aber nichts tut?
ZitatOriginal geschrieben von harlekyn
Offenbar jemand vom Fach, danke fuer die ausfuehrliche Erklaerung
Weisst du, wie genau diese 15 Sekunden definiert sind? Ist das tatsaechlich genutzte CPU-Zeit, oder zaehlt's auch wenn die App zwar aktiv ist, aber nichts tut?
Das ist eine gute Frage.
Die Mango-SDK-Doku erklärt das eigentlich nicht direkt. Jedenfalls habe ich bisher nichts eindeutiges dazu gefunden, nur einfache Beispiele und habe damit bisher nur simpelste Tests gemacht.
Eine Beschreibung findet sich aber hier:
http://msdn.microsoft.com/en-u…h202942%28v=VS.92%29.aspx
Da steht, dass ein "Periodic Agent" nur "typischerweise" alle 30 Minuten aufgerufen wird und für 15 Sekunden laufen kann. Wenn damit CPU-Zeit gemeint wäre, könnte er natürlich immer nach 10ms blockieren und damit doch alle 2,x Minuten oder so was machen, wie GPS abfragen oder so.
Ich denke aber, dass es nicht so gemeint sein kann. Zumindest wüsste ich nicht, wie man die Task blockieren sollte, um die CPU abzugeben. Also ohne die Task zu terminieren.
Im Gegensatz zu einer klassischen Windows-App, die bei echtem Multitasking in ihrem Event-Loop blockiert wird, hat die Background-Task von Windows Phone ja keine Event-Loop. Und einen CPU-Halt-Befehl kann man bei Managed Code ja auch nicht einschmuggeln... Also kann man die CPU nicht freiwillig abgeben, wie in echten Multitasking-Systemen (das alle normalen Prozesse im Hintergund bei echtem Multitasking, die gerade nichts zu tun haben, sinnlos CPU-Schleifen drehen und den Akku leersaugen würden, ist ja leider auch so eine urbane Legende die Apple leider geschafft hat, Multitasking anzudichten und die jetzt überall nachgebetet wird).
Jedenfalls, soweit ich bisher verstehe, kann man nur die Periodic-Task vorzeitig beenden oder eben nicht vorzeitig. Deswegen ist es wohl leider kein Zeitbudget.
ZitatOriginal geschrieben von tw2
Die Mango-SDK-Doku erklärt das eigentlich nicht direkt. Jedenfalls habe ich bisher nichts eindeutiges dazu gefunden, nur einfache Beispiele und habe damit bisher nur simpelste Tests gemacht.
Danke fuer den Link, eigentlich ist die Beschreibung da eindeutig. So ein PeriodicTask wird etwa alle 30 Minuten ausgefuehrt und hat dann etwa 15 Sekunden Zeit. Feste Garantien gibt's aber keine, es kann sein dass die Ausfuehrung auch mal 10 Minuten spaeter erfolgt und dass der Task schon vor Ablauf der 15 Sekunden beendet wird.
Fuer periodische Synchronisation, Standortupdates etc. genuegt das. Aber es eignet sich weder fuer einen Instant Messenger, der permanent im Hintergrund laeuft (es sei denn man ist mit bis zu 30 Minuten Verzoegerung bei der Zustellung einer Nachricht einverstanden), noch fuer Audiostreaming oder Navigation.
ZitatOriginal geschrieben von harlekyn
Danke fuer den Link, eigentlich ist die Beschreibung da eindeutig. So ein PeriodicTask wird etwa alle 30 Minuten ausgefuehrt und hat dann etwa 15 Sekunden Zeit. Feste Garantien gibt's aber keine, es kann sein dass die Ausfuehrung auch mal 10 Minuten spaeter erfolgt und dass der Task schon vor Ablauf der 15 Sekunden beendet wird.
Na ja, ich finde die Formulierung könnte trotzdem eindeutiger sein, was "for 15 seconds" bedeutet. Aber egal.
ZitatFuer periodische Synchronisation, Standortupdates etc. genuegt das. Aber es eignet sich weder fuer einen Instant Messenger, der permanent im Hintergrund laeuft (es sei denn man ist mit bis zu 30 Minuten Verzoegerung bei der Zustellung einer Nachricht einverstanden), noch fuer Audiostreaming oder Navigation.
Zusätzlich kommt bei dem ganzen Konzept noch die Schwierigkeit dazu, dass das eigene Prozesse sind. Also kann z.B. ein Socket der connected ist in der App nicht einfach im Background-Agent weiter bedient werden oder so, wenn die App gestoppt wird. Die Sockets werden einfach geschlossen und damit auch TCP-Verbindungen getrennt, auch wenn man nur für 1 Sekunde in die Wetter App wechselt oder so... Ganz grosser Sport.
Was Audio-Streaming angeht, gibt es dazu eine spezielle Klasse, nur für diesen Zweck, die dann nicht den Einschränkungen der normalen Background Tasks unterworfen ist. Ähnliches gilt für Datei-Downloads und -Uploads.
Für Navi, GPS-Tracking usw. gibt es aber leider nichts entsprechendes. Dafür wackelt jetzt aber der Avatar in Xbox besser rum. 
ZitatNein, das ist falsch bzw. Du hast nicht verstanden, wie das Taskswitching funktioniert. Wenn eine App eingefroren wird, wird sie nicht mehr scheduled. Sie ist einfach im RAM und wird nicht mehr ausgeführt, erhält keine Events usw.. Wenn sie nicht mehr scheduled wird, ist sie eingefroren. Das ist ein und dasselbe.
Den Terminus "eingefroren" gibt es in diesem Zusammenhang garnicht und den erfindest du mal eben frei.
Es ist schonn genauso wie ich es sagte, sie wird nicht mehr gescheduled bzw verbleibt im "suspended state". Beides ist fachlich korrekt, "eingefroren" dagegen Blödsinn.
ZitatIch glaube nicht, dass Du Mango selber schon ausprobiert hast. Aber ich schon. Außerdem kannst Du das, wenn Du mir nicht glaubst, in zig Videos, Berichten zu Mango selber sehen, sowie in der SDK - oder indem Du selber Mango installierst.
Tja, so kann man sich täuschen. Hab bereits viele der neuen APIs ausprobiert, was man offensichlich von dir nicht behaupten kann, wenn ich mal deine zaghaften Versuche mit den Periodic Agents als Beispiel nehme.
Wie dem auch sei, unsere Aussagen scheiden sich grundsätzlich nur am Wort "eingefroren".
ZitatIm Gegensatz zu einer klassischen Windows-App, die bei echtem Multitasking in ihrem Event-Loop blockiert wird, hat die Background-Task von Windows Phone ja keine Event-Loop.
Erstens hat man in einer klassischen (Win32) Windows-App keine Event-Loop sondern eine Message-Loop. Zweitens sind Events nicht die einzigen blockierenden Primitiven. Messages, Mutexes, Asynchroner I/O, diverse Handles (z.B. Thread Handles) gehören auch dazu. Hinzu kommen noch nicht sofort offensichtlich blockierende Primitiven wie z.B. bei Direct3d IDirect3DDevice9::Present, ansonsten wäre es auch problematisch ein Spiel zu programmieren, was nicht 100% Prozessor Leistung saugt.
Und nicht zu vergessen, das allseits beliebte System.Threading.Thread.Sleep()...
Belies dich am besten mal, bevor du hier wieder von dir gibst, dass CPU-Halt oder Events die einzigen Möglichkeiten sind einen Thread zu suspenden.
Zitatdas alle normalen Prozesse im Hintergund bei echtem Multitasking, die gerade nichts zu tun haben, sinnlos CPU-Schleifen drehen und den Akku leersaugen würden, ist ja leider auch so eine urbane Legende die Apple leider geschafft hat
Auch falsch. Richtig wäre: Bei unbeschränktem Multitasking kann jede Applikation potentiell sinnlos CPU-Schleifen drehen und den Akku leersaugen. Es gibt eben keine Garantie, dass sich eine Hintergrund-Applikation "anständig" verhält.
Gruß
Achso, die restlichen Schlussfogerungen sind soweit ich das bisher einschätzen kann korrekt. Ein Navi, welches kontinierlich GPS Informationen erhalten und verarbeiten muss etc. wird mit den in Mango vorhandenen Mitteln schwer umzusetzen sein, wenn im Hintergrund ist.
Eine Messenger App mit Background File transfers schon eher. In diesem Zusammenhang würde mich interessiert, wo du gelesen hast, dass sockets geschlossen werden, wenn eine Application suspended wird? Das wär in der Tat nicht sonderlich erfreulich.
ZitatOriginal geschrieben von Tala
Den Terminus "eingefroren" gibt es in diesem Zusammenhang garnicht und den erfindest du mal eben frei.
Es ist schonn genauso wie ich es sagte, sie wird nicht mehr gescheduled bzw verbleibt im "suspended state". Beides ist fachlich korrekt, "eingefroren" dagegen Blödsinn.
Du bist ja lustig. 
Beleidigte Leberwurst? Oder was soll das sinnfreie Rumschwafeln, denn jetzt? Du hast völligen Unsinn zu dem Unterschied zwischen NoDo und Mango geschrieben, was Multitasking angeht. Da helfen jetzt auch keine Spitzfindigkeiten über "fachlich korrekte" Terminologie.
Und "fachlich korrekt" ist ja sowieso völlig lachhaft. Nach DIN oder ISO oder was? Den Terminus "suspended state" oder "nicht gescheduled" gibt es bei Microsoft dafür auch gar nicht. Wenn Du unbedingt auf Denglisch rumschwafeln willst, dann wäre der richtge Terminus von Microsoft für den WP Application Lifecycle der "dormant state" gewesen. So nennt das MS.
Aber so affig zu reden und für "fachlich korrekt" zu halten, ist völlig albern. Tatsache ist, dass die Apps bei Mango im Speicher eingefroren werden. Das ist ein völlig gängiger und anschaulicher Begriff.
Zitat[...] sind Events nicht die einzigen blockierenden Primitiven. Messages, Mutexes, Asynchroner I/O, diverse Handles (z.B. Thread Handles) gehören auch dazu. Hinzu kommen noch nicht sofort offensichtlich blockierende Primitiven wie z.B. bei Direct3d IDirect3DDevice9::Present, ansonsten wäre es auch problematisch ein Spiel zu programmieren, was nicht 100% Prozessor Leistung saugt.
Und nicht zu vergessen, das allseits beliebte System.Threading.Thread.Sleep()... ...
Belies dich am besten mal, bevor du hier wieder von dir gibst, dass CPU-Halt oder Events die einzigen Möglichkeiten sind einen Thread zu suspenden.
Lege mir nicht irgendwelche Aussagen in den Mund. Von "einzigen" habe ich kein Wort geschrieben. Es geht hier um Windows Phone, nicht Desktop Windows.
Anscheinend hast DU leider überhaupt nicht verstanden, über welchen Kontext ich eigentlich geschrieben habe (nämlich Windows Phone Mango) und listest ganz stolz einfach sinnfrei irgendwelche Möglichkeiten vom normalen Desktop Windows auf, wie Prozesse/Threads synchronisieren (Mutexes), was in dem Zusammenhang keinen Sinn macht, weil nur ein Background Task erlaubt ist pro App, aber die App selber eingefroren ist (:p, ja eingefroren). Mal abgesehen davon, dass das gar nicht das Thema war, Threads in der Background Task zu synchronisieren.
Und Direct3D ist in der Background Task gar nicht erlaubt, schon mal weil Du auf WP gar keine zugängliche C/C++ Direct3D-API hast... Aua Was hast Du noch mal alles schon getestet? Weißt Du überhaupt wovon Du redest? Es gibt nur XNA für C# und auch das darf man generell nicht in der Background Task nutzen. Asynchronous I/O könnte man jetzt viel zu schreiben, welche I/O und welche API hier konkret gemeint sein ist. Im Kontext von GPS-Tracking hat man eine Location API. Die ist zwar asynchron, aber das nützt nichts, asynchron Events empfangen zu wollen, wenn der Thread der sie empfangen soll terminiert werden kann. Thread.Sleep() würde ja in dem Zusammenhang allenfalls Sinn mit Sleep(0) Sinn machen, aber wenn man das in der Background Task aufruft, ist nicht nur die CPU weg, sondern auch der Thread. (Bei Mango Beta.)
Ich glaube nicht, dass Du überhaupt schon irgendwelche Tests mit Mango APIs gemacht hast, nicht mal "zaghafte".
ZitatAuch falsch. Richtig wäre: Bei unbeschränktem Multitasking kann jede Applikation potentiell sinnlos CPU-Schleifen drehen und den Akku leersaugen. Es gibt eben keine Garantie, dass sich eine Hintergrund-Applikation "anständig" verhält.
Lege mir nicht dauernd irgendwelche Aussagen in den Mund, nur damit Du "beweisen" kannst, dass Du nicht so ahnungslos bist, wie es oben schien. Was ich schrieb war:
"das alle normalen Prozesse im Hintergund bei echtem Multitasking, die gerade nichts zu tun haben, sinnlos CPU-Schleifen drehen und den Akku leersaugen würden, ist ja leider auch so eine urbane Legende die Apple leider geschafft hat, Multitasking anzudichten und die jetzt überall nachgebetet wird"
ist vollkommen korrekt. Lies mal richtig: Es ist eine Legende das alle normalen_ Prozesse ... den Akku leersaugen". Und das ist eine Legende. Irgendwelche Aussagen zu "unbeschränktem" Multitasking (geschweige denn das es nur die Alternative zwischen "unbeschränktem" und Single-Tasking gibt) habe ich damit nicht getroffen. Insbesondere ist es sehr wohl möglich, flexiblere Systeme zu bauen, als wie es jetzt in Mango implementiert ist, die einen Mittelweg finden.
Das ist eigentlich ein interessantes Thema, aber hier off-topic und im Kontext eines Streits im Grundschul-Stil "ich weiß ja viel mehr als Du, ätsch", völlige Zeitverschwendung.
ZitatOriginal geschrieben von Tala
Achso, die restlichen Schlussfogerungen sind soweit ich das bisher einschätzen kann korrekt. Ein Navi, welches kontinierlich GPS Informationen erhalten und verarbeiten muss etc. wird mit den in Mango vorhandenen Mitteln schwer umzusetzen sein, wenn im Hintergrund ist.
Nicht schwer, sondern gar nicht.
ZitatEine Messenger App mit Background File transfers schon eher. In diesem Zusammenhang würde mich interessiert, wo du gelesen hast, dass sockets geschlossen werden, wenn eine Application suspended wird? Das wär in der Tat nicht sonderlich erfreulich.
Ganz einfach. Ich habe es schon länger getestet. Ich dachte Du hast auch schon so viel getestet.
Aber höre Dir z.B. WP Dev Podcast an, da wurde das auch schon bemängelt.
PS:
Ist aber auch völlig logisch, da die App nun mal in der Tat eingeforen ist ("dormant state"). Zwar muss man keine neue Instanz des Socket-Objekts anlegen, aber die eigentliche TCP-Connection ist weg. Je nach sessionorientiertem Protokoll, was über TCP läuft (bitte jetzt nicht wieder spitzfindig werden), ist dann auch die Session weg, man muss Socket.ConnectAsync wieder aufrufen und soweit ich bisher getestet habe hat man auch immer einen neuen lokalen Port, was auch logisch ist.
Da eine App ja beliebig lange eingefroren sein kann, ist das auch zu erwarten, da die TCP-Verbindung ja sonst austimen würde.
[Doppelpost wg. Netzwerkproblem]
ZitatAber so affig zu reden und für "fachlich korrekt" zu halten, ist völlig albern. Tatsache ist, dass die Apps bei Mango im Speicher eingefroren werden.
Und genau das ist keine Tatsache, wie bereits oben angemerkt. Da friert garnichts, noch nichtmal im übertragenen Sinne. Ich wär garnicht drauf eingegangen, wenn du nicht begonnen hättest auf diesem Begriff rumzureiten.
Eigentlich hattest du meinem original Post nicht sinnvolles hinzuzufügen, ausser dass eben doch "eingefroren" wird.
ZitatAnscheinend hast DU leider überhaupt nicht verstanden, über welchen Kontext ich eigentlich geschrieben habe (nämlich Windows Phone Mango) und listest ganz stolz einfach sinnfrei irgendwelche Möglichkeiten vom normalen Desktop Windows auf
Der Kontext ist mir bewusst, allein mir fehlt der Glauben, dass du verstehst was du da von dir gibst:
ZitatIm Gegensatz zu einer klassischen Windows-App, die bei echtem Multitasking in ihrem Event-Loop blockiert wird, hat die Background-Task von Windows Phone ja keine Event-Loop
Ich habe angemerkt, dass a) eine landläufige Win32 App zwar über eine Message Loop verfügt aber, im Gegensatz zu deiner Behauptung keine Event-loop. und b) Dass dein Satz impliziert, dass Events die einzige Möglichkeit sind einen Thread zu suspenden, was wiederum auch nicht stimmt.
Ansonsten würde der Satz :
"Im Gegensatz zu einer klassischen Windows-App, die bei echtem Multitasking bei IDirect3DDevice9::Present blockiert wird, hat die Background-Task von Windows Phone ja keine unterstützung von Direct3d".
Dieser Satz ist aus exakt dem selben Grund sinnfrei, weil mein Satz ebenso impliziert, dass es ausser IDirect3DDevice9::Present keine weitere Möglichkeit zum suspenden existiert. Von Logik hälst du wohl nicht viel?
Aus diesem Grund habe ich mir auch erlaubt Beispiele sowohl aus der Win32 als auch aus der .Net Welt zu benutzen.
Zitatist vollkommen korrekt. Lies mal richtig: Es ist eine Legende das alle normalen_ Prozesse ... den Akku leersaugen". Und das ist eine Legende. Irgendwelche Aussagen zu "unbeschränktem" Multitasking (geschweige denn das es nur die Alternative zwischen "unbeschränktem" und Single-Tasking gibt) habe ich damit nicht getroffen.
Jetzt wird es aber abenteuerlich. Du meinst ernsthaft es ist ein positives Beispiel, dass nicht _alle_ Prozesse den Akku leersaugen, sondern nur _einige_?
Da weiss ich garnicht, ob ich dieser geistigen Ergüße weinen oder lachen soll.
ZitatNicht schwer, sondern gar nicht.
Meine Aussage bezog sich auf die Tatsache, dass sowohl Mango, das SDK und die Doku beta Status haben. Mit den momentanen Mitteln geht es sicherlich nicht.
ZitatGanz einfach. Ich habe es schon länger getestet. Ich dachte Du hast auch schon so viel getestet.
Entschuldige, dass ich nachgefragt habe. Socket Verbindungen im supended state standen nicht allzu hoch auf meiner Prioritätsliste. Immer wieder schön, eine sachliche Antwort zu bekommen. Wie war das nochmal mit dem Grundschul-Stil?
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!