Jeśli chcecie mnie wesprzeć to zapraszam do kupna mojego poradnika "Jakim jesteś Makiem?".

Fragmentacja Androida na przykładzie BBC iPlayer →

· Wojtek Pietrusiewicz · 6 komentarzy

Jonny Evans:

The BBC Trust today responded to a complaint the broadcaster favored iOS devices when it comes to adding features to its catch-up on demand iPlayer service for Android phones. This complaint was rejected because the Trust found “no evidence” to suggest iOS had been “unfairly favored.”

Instead of pro-Apple favouritism, the Trust found a series of quite logical reasons why Android lagged iOS when new features were added to iPlayer, mostly surrounding the “complexity and expense” of developing for Android.

BBC ponadto twierdzi, że kodowanie na Androida jest bardziej skomplikowane i droższe, a jeśli do tego dodać mniejszą ilość aktywnych użytkowników, to całość ma mniejszy sens niż tworzenie dla iOS. Prawda jest taka, że na rynku znajdziemy obecnie tysiące urządzeń z Androidem, każdy z innym procesorem, rozmiarem ekranu i jego rozdzielczością oraz o różnej wydajności. Nie da się fizycznie sprawdzić działania aplikacji na każdym z nich, a nawet weryfikacja jedynie garstki tych telefonów i tabletów wiąże się z ogromnymi dodatkowymi kosztami. Skoro ma to znaczenie dla takiego giganta jakim jest BBC, to tym bardziej musi być to uciążliwe dla małych developerów. Google ma długą drogę przed sobą, ale mam wrażenie, że jest im to obojętne.

Chcesz zwrócić mi na coś uwagę lub skomentować? Zapraszam na @morid1n lub na forum.

  • Ale nie do każdego typu oprogramowania trzeba robić takie testy i tyle się męczyć. BBC ma zapewne problem, bo bawią się z kodekami wideo. Te z kolei są pisane raczej w kodzie natywnym, a więc i zależnym od procesora. Stąd problemy. Ale już dajmy na to klienta Google Readera czy Twitttera to nie dotyczy. Tutaj jedyny kłopot, to dostosowanie do różnych rozdzielczości (co da się zrobić w emulatorze i ostatnio bezpośrednio w Android Studio), kwestia wydajności i ewentualnie bugów w ROMach producentów.

  • Nie do końca, bo patrząc na samego Twittera to np. na telefonach HTC masz ten bezsensowny pasek na dole.

  • Ale to wina kombinowania HTC (za cudowanie z przyciskami sprzętowymi zamiast ekranowych) i programistów Twittera (bo nie chcieli się przystosować do Andka 4.x), nie Google’a. A i tak nawet z tym paskiem rozdzielczość jest w miarę standardowa, bo identyczna jest na Nexusach z ekranowymi przyciskami nawigacji.

    Problem pojawia się jedynie na tańszych modelach HTC (z ekranami WVGA i niżej), które mają nowy układ przycisków pod ekranem. Przy czym patrząc na podawane liczby dotyczące ilości sprzedanych urządzeń i udziału poszczególnych producentów, to tanie słuchawki HTC stanowią prawdopodobnie na tyle mały procent rynku, że programiści są skłonni olać problem paska menu na nich.

  • JebaczKoz

    “Prawda jest taka, że na rynku znajdziemy obecnie tysiące urządzeń z Androidem, każdy z innym procesorem, rozmiarem ekranu i jego rozdzielczością oraz o różnej wydajności. Nie da się fizycznie sprawdzić działania aplikacji na każdym z nich, a nawet weryfikacja jedynie garstki tych telefonów i tabletów wiąże się z ogromnymi dodatkowymi kosztami.”

    Fajna bajeczka, a prawda jest taka że nikt nie tworzy na te najtańsze smartfony. Gdyż najtańszy smartfon zastąpił proste telefony. Producentowi jest prościej wydać bardzo budżetowego smartfona na Androidzie niż bawić się w projektowanie kolejnych.

    Reasumując Moridin, ty jako programista wiesz że tak jest, to co wypisuje łeb od programowania zatrudniony przez BBC? Sam znasz jedną jak i druga platformę, jej plusy i minusy.

    Raz jeszcze podkreślę najwięksi działacze skupiają się na najlepiej sprzedawanych produktach – Oni z określeniem się i połapaniem w programowaniu na jakąkolwiek platformę problemu nie mają. Tak jest to iPhone ale jest to również Samsung Galaxy, HTC…., Sony…, itd

  • Uważam jednak, że to problem “dla Google”, bo to oni najwięcej tracą.

  • belike81

    Akurat kodeki wideo nie są problemem. Do tego są odpowiednie biblioteki. Natomiast problemem jest różnorodność rozdzielczości w Andku, co za tym idzie różnorodność layout’ów (urządzenie 3-4 cale, 4-5, 5-7, 9-10). Do tego dodaj wersje API w zależności od docelowej wersji systemu i robi się malutki burdel, a różnice w API nie są znowu takie niewielkie. Bez porządnego testowania na różnych modelach się nie obędzie (bez tego zaraz zaliczysz pełno jednogwiazdkowych opini z których już się nie wykaraskasz).