Sauber durch die Zertifizierung
Einleitung:
Dieser Artikel soll helfen, Apps ohne größeren Ärger durch die Zertifizierung zu bringen.
Ich bin trotzt einiger Unstimmigkeiten immer noch davon überzeugt, dass das Zertifizierungsteam ordentliche Arbeit leistet und auch Sachen testet, auf die man einfach im Vorfeld nicht unbedingt kommt, die dann aber doch Sinn machen.
Aus gemachten Erfahrungen soll man ja bekanntlich lernen und diese möchte ich hier gerne teilen.
1. Erfahrungen aus dem Seller Office
Hier sind mir bisher 2 Punkte aufgefallen.
- Das Store Logo in 135x135px
Hier lauert ein erster Stolperstein, der eine Zertifizierung verhindern kann.
100%ig fährt man hier, wenn das Store Logo und das App Icon [bis auf die Größe
] identisch sind.
Ist die Abweichung zu groß [nach Gusto der Zertis] scheiterts hier schon. - Upload und Reviewboard - Kommentar -- Vorsicht Sonderzeichen
Hat zwar mit der Zertifizierung nichts zu tun, ist aber ärgerlich, wenn man nicht breitbandig Uploaden kann
Der Ablauf auf der Upload Seite ist folgender.
Wenn man die Datei angegeben und noch einen Kommentar für die Zertis eingegeben hat, klickt man am Seitenende auf "Continue", worauf der Upload beginnt und dann der Kommentar übertragen wird, AUSSER man hat unerlaubte Sonderzeichen im Kommentar verwendet, dann war der Upload für *##'+* und man rätselt, welche Zeichen denn jetzt verboten sind.
Scheinbar alles, was nach HTML aussehen könnte.
Benutzt zu den normalen Satzzeichen . , ! ? am besten nur _ und -.
Achtung: -- geht z.B. auch nicht. Und probiert auf keinen Fall smilies.
Das Problem ist gemeldet und Samsung hat versprochen, dass in Zukunft erst der Kommentar geprüft wird und dann der Upload startet
- Splashscreen und Icon
Sollte bekannt sein: Man darf für die eigene App logischweise nicht den Standard - Startbildschirm und das Standard - Icon benutzen. - Die Sache mit dem "lautlos" Modus
Möchte man die eigene App mit Geräuschen und Musik ausstatten, muss man, befindet sich das Gerät im "lautlos" Status, beim Start der App ein Popup einblenden.
Dieses fragt dann freundlich, ob Krach gemacht werden darf oder man lautlos weiter machen möchte.
[Osp::System::SettingInfo Class]gibt für muted "true" zurück, wenn das Gerät auf "lautlos" gestellt ist.Code: Select all
bool muted; SettingInfo::GetValue(L"SilentMode", muted); - Ohh, ein Headset und das im "lautlos" - Modus
Interessant ist das Verhalten von bada, wenn man während des Abspielens mittels des Players [Osp::Media::Player Class] einen Kopfhörer oder Headset anstöpselt und dann wieder entfernt, denn dann ist Schluss mit der Ausgabe.
(Der Player läuft munter weiter.)
Hier hilft [Osp::System::IDeviceEventListener Interface], wobei hier dann aber leider die Kompatiblität zum bada 1.0x Framework flöten geht.
Für jedes zu überwachende "Gerät" muss ein eigener Listener hinzugefügt werden:Wenn jemand das Verhalten kennt und eine schönere Lösung hat, vorallem für bada 1.0, dann bitte raus damit.Code: Select all
Osp::System::DeviceManager::AddDeviceEventListener(WiredHeadset, *this); Osp::System::DeviceManager::AddDeviceEventListener(WiredHeadphone, *this); Osp::System::DeviceManager::AddDeviceEventListener(TvOut , *this); void YourApp::OnDeviceStateChanged (Osp::System::DeviceType deviceType, const Osp::Base::String &state) { AppLog("Device Event empfangen !!!! DeviceType: %d / State: %S" , deviceType, state.GetPointer()); /* Wenn man's denn unterscheiden will switch(deviceType) { case 3: AppLog("TvOut"); break; case 4: AppLog("WiredHeadset "); break; case 5: AppLog("WiredHeadphone "); break; } */ // Oder einfach, egal was entfernt wurde: if (state == "Removed") { AppLog("Eines der Geraete wurde entfernt"); // Einmal kurz das aktuelle Playback pausieren und dann weiter abspielen ! :-) } }
So, das soll's von mir an dieser Stelle erstmal gewesen sein.
Wenn Ihr Fehler und/oder Unfug seht, bitte kommentieren.
Ich würde hier gerne weiter sammeln und hoffe ich kann hiermit bereits helfen.
Grüße
Christian
