Beiträge von tw2

Ja, entweder das oder alternativ kann man den Google Play Store dank der Arbeit des Users Cobalt232 bei Crackberry auch direkt installieren, indem man drei APKs in der richtigen Reihenfolge installiert:

http://forums.crackberry.com/a…uying-downloading-985344/

Zitat

Original geschrieben von Anja Terchova
Geraete mit 4:3 Screen sind aber fast ausgestorben, also macht es keinen Sinn mehr darauf zu optimieren, wenn es kaum noch Geraete gibt.

Heute sind die allermeisten Geraete mit 16:9 oder 16:10 Screen. Bei den Smartphones 960x540 bis 2.560x1.440 Pixel und bei Notebooks und PCs 1.366x768 bis 2.560x1.440 Pixel.

Danach kommen dann wohl noch die 21:9 Geraete vor den letzten 4:3 Geraeten.

... und wer heute noch nur auf bestimmte Bildschirmgrößen optimiert, ist in den 2000er Jahren hängengeblieben. Aber Webseiten wurden sowieso nie auf 16:9 optimiert. Jedenfalls nicht von Webdesignern die wissen was sie tun. Da hat Timba69 recht.

Abgesehen davon stimmt es auch faktisch nicht, was Du schreibst. Denn da sämtliche Apple iPad alle 4:3 haben, und davon mehr verkauft worden sind und werden als von jedem anderen Tablet wird das Format auf Jahre hinaus unterstützt werden müssen. Es ist nicht absehbar das Apple davon abweicht.

Auch bei den neuesten Tablets anderen Hersteller wie Samsung Galaxy Tab S2, Galaxy Tab A, Google Nexus 9, HP Pro Slate 8 und 12 und diversen anderen Geräten z.B. von Acer, Archos kommt 4:3 neuerdings wieder zum Einsatz.

Ich glaube nicht, dass das da 95% der Apps vom Play Store sind.

Wenn es um den Play Store geht, kann man ja gleich Snap installieren.

Seit ein paar Tagen ist die neueste Version 1.1.1.26 von BB Link verfügbar:

http://de.blackberry.com/softw…ktop/blackberry-link.html

Damit ist jetzt die bidirektionale Synchronisation mit Outlook für Kontakte und Kalender möglich. Ich habe es gerade installiert und man kann das jetzt aktivieren und konfigurieren. Ich habe es allerdings selber noch nicht ausprobiert, da ich ja mit einem gemieteten Exchange-Konto arbeite.

Ein paar Punkte: Diese Diskussion geht ja schon fast 10 Jahre.

Daher sollte man zunächst mal den alten Begriff "USB Sync" (oder "Kabel Sync") vergessen. Man kann nämlich heute auch (je nach Gerät und OS) mit USB mit entfernten Servern oder der Cloud syncen bzw. umgedreht kann man auch über eigenes WLAN oder sogar über Mobilfunk mit dem PC oder Server bei sich zu Hause syncen. -- Also jetzt mal ganz allgemein gesprochen. Ob das im Einzelfall überhaupt immer und wie das bei verschiedenen Mobilbetriebssystemen geht ist natürlich unterschiedlich.

Bei BB10 würden grundsätzlich alle diese Varianten gehen, wenn das jemand implementiert. Wie man z.B. an Companionlink sieht. Den BB10 ist nicht so vernagelt wie einige andere Systeme, die ich jetzt mal nicht nenne, da ich keine Fanboy-Diskussion starten will.

BB10 ähnelt in dieser Hinsicht, was diese grundsätzlichen Möglichkeiten für die Entwickler angeht, dem alten Windows Mobile (vor Windows Phone) und ist aber trotzdem sicherer.

Jedenfalls, wie auch immer, die Hauptfrage ist eigentlich nur ob man die eigenen Daten:

(A) komplett oder teilweise in der eigenen Hoheit haben will

oder

(B) bei einem externen (kostenlosen oder kostenpflichtigen) Dienstleister ablegen will

Wenn man sich (wirklich!) darüber klar ist, dass man (A) unbedingt will oder sogar eventuell aus rechtlichen Gründen machen muss (z.B. als Firma oder Behörde wegen Datenschutz oder Wahrung von Geschäftsgeheimnissen oder Copyright) sind externe Exchange Anbieter unter Umständen schon außen vor. Wobei es da auch Möglichkeiten gibt, zumindest solange die Server des Dienstleisters wirklich innerhalb der EU liegen und niemals außerhalb der EU bzw, Ländern gelangen die mit der EU entsprechend Verträge haben (Vertrag zur Auftragsdatenvereinbarung). Wobei ich dazu nicht das "Safe Harbor" Abkommen zähle, was man mit den USA geschlossen hat, den das ist eher ein Witz. Da kommen in den Fällen dann Outlook.com / Google usw. nicht mehr in Frage. Auch so was wie Office 365 ist eventuell fragwürdig. Offiziell läuft das ja in Amsterdam und Dublin für Europa, aber dazu habe ich auch schon gelesen, dass einige Leute festgestellt hatten, dass ihre virtuellen Server in den USA lagen.

Aber es gibt ja genug deutsche Hoster und Cloud Anbieter, die sich an das deutsche Datenschutzrecht und auch Urheberrecht halten müssen.

Was rein private Nutzung angeht, muss das auch jeder für sich entscheiden, wieviel Komfort man will und ob man dafür die eigenen Daten einem der kostenlosen Dienste anvertrauen will oder nicht. Klar ist das der kostenlose Dienstanbieter, sich irgendwie finanzieren muss, also die Daten irgendwie nutzen wird...

Außerdem kann es auch technische Gründe geben, die gegen kostenlose Anbieter sprechen. Z.B. bei Hotmail/Outlook.com werden nicht alle Attribut-Felder aller Objekte in der vollen Länge abgeglichen. Jedenfalls bis letztes Jahr. Vielleicht ist das jetzt behoben. Zum anderen war der Hotmail-Connector für Outlook 2010 beim Syncen sehr langsam. Mit Outlook 2013 kann man allerdings jetzt auch EAS nutzen und braucht den Connector nicht mehr.

Aber richtige, volle Exchange Konten bei einem deutschen Hoster mit Standort Deutschland zu mieten, kostet aber auch nicht mehr die Welt (für maximal 10 Euro im Monat gibt es typischerweise sogar schon 25 GB Postfächer).

Bidirektionaler Abgleich zwischen Outlook und BB10 kommt leider erst mit der nächsten Version von BB Link.

Alternativ kann jetzt Companionlink wohl auch Outlook mit den Daten der eingebauten BB10 Apps syncen (bislang ging nur das Syncen mit einer speziellen BB10 App von denen). Kostet aber relativ viel, obwohl es zur Zeit einen Rabatt für BB10-Besitzer gibt:

http://www.companionlink.com/products/bb10-outlook.html

Ich habe das aber bisher selber nicht probiert und kann dazu auch nichts weiter sagen. Es gibt zwar eine Testversion, aber da ich schon seit Jahren ein für ein paar Euro gemietetes Exchange-Konto verwende, was ich nicht verwalten muss, interessiert mich der rein lokale Sync selber auch nicht so besonders mehr (habe ich auch schon vor BB10 nicht mehr gemacht).

Wollte es aber erwähnen.

Zitat

Original geschrieben von Tala
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.

:confused: Das ist wirres Zeug. Es wird ja eingefroren, natürlich im übertragenen Sinne. Oder willst Du mir jetzt erklären, dass das Gerät nicht unter den Gefrierpunkt sinkt oder was?

Oder warum Deine erfunden Begriffe wie "nicht gescheduled" angeblich "fachlich korrekt" sind und wo Microsoft diese eigentlich verwendet? "Gescheduled" kann ich in der Mango Doku nicht finden. Wie bereits gesagt, nennt Microsoft das "dormant state".

Du kannst gerne noch weiter auf der Terminologie rumreiten, aber ich klinke mich da mal aus. Fakt bleibt, dass Du selber behauptet hast, dass in NoDo eingefroren wird, was aber faktisch und sachlich falsch ist. Zwar gab es den "dormant state" wie es korrekt heißt auch schon. Aber im Regelfall werden in NoDo Apps ge-tombstoned (auch so ein Denglisher Kauderwelsch) und bleiben eben nicht im RAM. Außer mit einem bestimmten Registry-Patch.

Zitat

Der Kontext ist mir bewusst, allein mir fehlt der Glauben, dass du verstehst was du da von dir gibst:

Das scheint mir aber doch so zu sein, da Du völlig irrelevante Sachen zum Desktop-Windows ins Spiel bringst, und mich damit und anderen Binsenweisheiten irgendwie "belehren" willst oder über nebensächliche Spitzfindigkeiten diskutieren willst. Alles völlig am Thema vorbei.

Zitat

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.

Die Begriffe Event Loop und Message Loop sind in der Informatik in dem Zusammenhang hier völlig synonym:
http://en.wikipedia.org/wiki/Event_loop

Ansonsten korrigiere bitte den Artikel in Wikipedia. Wahrscheinlich weißt Du da viel besser bescheid als die Autoren da und kannst denen mal erläutern, wo Du da die fundamentalen Unterschiede verortest. Da Du aber nun auch nicht in jedem Fall wie z.B. beim "dormant state" die Begrifflichkeiten von Microsoft verwendest, kannst Du Dich nicht darauf berufen, dass Microsoft die Event Loop "Message Loop" nennt. Fair ist fair. (Und verschone mich bitte ggf. auch damit mir erklären zu wollen, wo der Unterschied zwischen "Message" und "Event" in dem Kontext sei. Nur für den Fall, dass Du auf die Idee kommst, damit einen Punkt machen zu wollen. )

Da ich für meinen Teil nicht nur für Win32-Plattformen beruflich entwickele, verwende ich sie seit fast 20 Jahren synonym und habe daher auch leider keine Zeit mich hier über Deine völlig nebensächlichen Spitzfindigkeiten zu streiten, mit denen Du anscheinend von Deinem einleitenden eigenen Fehler ablenken willst.

Zitat

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 :
[...]

Einen Satz der das "impliziert", insbesondere für Windows Client, Windows Server und was weiß ich für Plattformen, habe ich so nicht geschrieben, schon gar nicht in Deiner Interpretation! Nochmal: höre auf mir irgendwas zu unterstellen und zitiere gefälligst korrekt!

Ich habe keine Zeit mich damit zu beschäftigen, dass Du mir irgendwelche Aussagen immer leicht verdreht in den Mund legst und dann aufwändig dagegen versuchst um drei Ecken herum zu argumentieren. Nach dem Motto: "um zu laufen musst Du einen Fuß vor den anderen setzen. Das kannst Du nicht gewusst haben, weil Dein Satz impliziert ja, dass man nur Auto fahren kann". Oder so ähnlich.

Deswegen gehe ich auch nicht mehr darauf ein, was Du im Anschluss wieder vollkommen sinnlos an meinen Aussagen irgendwie zickig verdrehst. Was auch sowieso nirgendwo hinführt. Das ist alles völlige Zeitverschwendung und sehr langweilig. Besonders wenn Du dann auch noch mit 08/15-Kram kommst, wie einer im ersten Semester.

Lies noch mal langsam (im Kontext von Windows Phone hier!) was ich eigentlich geschrieben habe. Und wenn Dir dann noch was logisch sinnvolles einfällt, was irgendwie mit dem zu tun hat, was ich am Ausgangspunkt zu den Einschränkungen des Multitaskings unter WP eigentlich geschrieben habe, lasse es mich wissen.

Zitat

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?

Der Satz bezog sich lediglich darauf, dass Du oben damit geprahlt hast, wie viele APIs Du alles schon von Mango getestet hast, im Gegensatz zu meinen "zaghaften" Versuchen, die Du mir unterstellt hast. Da die Socket-Unterstützung einer der wichtigsten Neuerungen von Mango ist (aber bitte jetzt nicht mit mir auch noch darüber streiten), hätte ich angenommen, dass Du schon mal gemerkt hast, dass die TCP-Verbindungen abbrechen, wenn die Apps eingefroren werden. Jedenfalls wenn man so viele APIs testet wie Du.

Wie es in den Wald hineinruft, so schallt es eben heraus. Da brauchst Du sicherlich nicht allzu sehr zu jammern.

[Doppelpost wg. Netzwerkproblem]

Zitat

Original 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.

Zitat

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.

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.

Zitat

Original 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".

Zitat

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.

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.