Android Flame War

[Berion]

IDE? dlaczego nie SATA? Jakieś opłaty licencyjne czy ki diabeł?

[pali]

Tak być może. Minimalna opłata za SATA to około miliona dolarów.

Mam takie info od polskiego producenta pewnych układów działających na IDE, który nie rozpoczął produkcji SATA właśnie z tego powodu. Ale to była taka bardzo ogólna informacja, szczegółów nie znam.

[Berion]

Nie chce wkładać kija w mrowisko, ale serio, dzisiaj zmiękły mi kolana. Jak zobaczyłem pierdyliard rozdziałek pod które muszę przygotować grafikę...

http://developer.android.com/guide/p...s_support.html

[andy]

Czytamy

. You do not need to provide alternative resources for every combination of screen size and density. The system provides robust compatibility features that can handle most of the work of rendering your application on any device screen, provided that you've implemented your UI using techniques that allow it to gracefully resize (as described in the Best Practices, below).

[sobrus]

No chyba że bedzie chciał zeby na każdym wygladało na max mozliwości. Wtedy faktycznie nie będzie różowo
Ale tak czy inaczej wydaje mi sie że kilka wersji to raczej minimum...

[Berion]

No tak tylko, że ja nie mam kontroli nad algorytmem używanym do skalowania, a sam pomysł na skalowanie o tak różnych proporcjach znacząco obniża jakość przeskalowanej grafiki (już nie wspominając o innych elementach ui, które trzeba dostosowywać do każdej rozdziałki). Do tego dochodzą, różne wartości ppi dla różnych telefonów i nie wiadomo do końca na które się decydować.

Mówimy tutaj o grze 2d. Przy aplikacjach czy grach 3d ten problem jest raczej nieduży.

[M@X]

Bylo pisac na iOSa? ;-)

[Berion]

A masz na zbyciu cztery koła?

[sobrus]

http://allegro.pl/apple-iphone-2g-8g...664315385.html


A tak na marginesie dziś miałem głupi sen.
Śniło mi się że kupiłem Tacie najnowszego iPhone za 2899.
Super ekran system fajny itd (choć z iOS to on wspólnego nic raczej nie miał).
Ale najbardziej mnie (przynajmniej po obudzeniu) rozbawił wybór sieci:

Select wireless network:
- Bluetooth (sucks!)
- WiFi (sucks!)
- Apple Wireless (rocks!)

[ed hunter]

Z takim pęknięciem, to ekran dotykowy raczej działać nie może, ale co tam, ajfon, liczy się sztuka!

[andy]

@Berion dalej nie widzę aż takiego problemu...

Ile masz różnych proporcji do opanowania 3-4 ? Dla każdej robisz jedną grafikę i skalujesz w dół - nie masz efektu kiedy proporcje się pierdzielą. Skalowanie w dół dla tej samej proporcji ekranu nie ponosi strat.


U siebie mam 540x960=1.78. Wystarczy, że zrobisz grafikę dla rozdzielczości 1080x1920 dla nasycenia high dpi (~320), dla medium, oraz low( akurat to zrobisz z automatu).
Czyli tworzysz 4 wersje(1:78, 1:33, 1:68, 1:2) jednej tej samej grafiki(oczywiście jeżeli nie korzystasz z kontrolek systemowych - one są uniwersalne).
Programem graficznym obniżasz
Potem Android sam zeskaluje do odpowiedniej rozdzielczości. Oczywiście dla lepszej wydajności możesz to zrobić programem.

No chyba, że bredzę to proszę o naprostowanie.


Btw, zerknij też na to:

Density-independent pixel (dp)A virtual pixel unit that you should use when defining UI layout, to express layout dimensions or position in a density-independent way. The density-independent pixel is equivalent to one physical pixel on a 160 dpi screen, which is the baseline density assumed by the system for a "medium" density screen. At runtime, the system transparently handles any scaling of the dp units, as necessary, based on the actual density of the screen in use. The conversion of dp units to screen pixels is simple: px = dp * (dpi / 160). For example, on a 240 dpi screen, 1 dp equals 1.5 physical pixels. You should always use dp units when defining your application's UI, to ensure proper display of your UI on screens with different densities.

Here is a quick checklist about how you can ensure that your application displays properly on different screens:

1. Use wrap_content, fill_parent, or dp units when specifying dimensions in an XML layout file
2. Do not use hard coded pixel values in your application code
3. Do not use AbsoluteLayout (it's deprecated)
4. Supply alternative bitmap drawables for different screen densities

Tutaj wszystko ładnie opisane developer.android.com/guide/practices/screens_support.html
dodatkowo zerknij na tę aplikację - https://github.com/github/android - podobno jedna z lepiej napisanych.

Btw, na iOS wcale się tak łatwo nie pisze. Polecam zerknąć na pewien wywiad na stronie MacKozera odnośnie pisania aplikacji


Jeszcze wracając na chwilę do rozpoczęcia tworzenia aplikacji na Androida. Koszt zerowy jeżeli zamiast fizycznego telefonu chcemy testować na emulatorze.
W przypadku Apple? Komputer - ~4k, SDK - 99$...

Do tego 30% od każdej aplikacji, w Androidzie możesz umieścić poza sklepem i mieć wszystko dla siebie.
Po jakim czasie zwróci się te 4.5k jakie wydałeś na sprzęt Apple?

[M@X]

Szybko, biorac pod uwage skale piractwa na obu platformach... Rozmawialem o tym wczoraj z Berionem i zgodzilismy sie w tej kwestii.

Prostuje - SDK jest darmowe (XCode w App Store).

[sobrus]

@Andy
Nie bredzisz, dobrze prawisz. Tak mi się wydaje.

Co by jednak nie mówić, już te cztery podstawowe wersje to całkiem sporo.

A to zakładając tylko że zrobi najwyższe rozdzielczości.

Nie wiem jakie grafiki ma Berion, ale nie wszystko da sie przeskalować.
Niektóre ręcznie tworzone nie przeżyją żadnego skalowania.
Np biała linia grubości 1 piksela na czarnym tle nie da się przeskalować w dół żadnym algorytmem, aby dobrze wygladała.
Jeżeli to takie grafiki to każdą niestety trzeba przygotować oddzielnie.

[Bartez]

Napisany przez andy

Jeszcze wracając na chwilę do rozpoczęcia tworzenia aplikacji na Androida. Koszt zerowy jeżeli zamiast fizycznego telefonu chcemy testować na emulatorze.
W przypadku Apple? Komputer - ~4k, SDK - 99$...

Do tego 30% od każdej aplikacji, w Androidzie możesz umieścić poza sklepem i mieć wszystko dla siebie.
Po jakim czasie zwróci się te 4.5k jakie wydałeś na sprzęt Apple?

A ta aplikacja na Androida to będzie pisana na liczydle, czy jednak też potrzebujesz do tego komputer, na który trzeba wydać przynajmniej 2k (szału nie będzie na pewno)? I jak szybko on się zwróci? Może jednak zastosować podobną miarę, jak już chcesz coś porównywać, bo od jakiegoś czasu zaczynasz mocno przeginać w stronę androida.

[andy]

Napisany przez Bartez

A ta aplikacja na Androida to będzie pisana na liczydle, czy jednak też potrzebujesz do tego komputer, na który trzeba wydać przynajmniej 2k (szału nie będzie na pewno)?

W przypadku Beriona odpada koszt zakupu komputera. Plusem rozpoczęcia programowania na platformę Android jest to, że SDK masz na każdą platformę.

Oczywiście w przypadku kiedy ktoś nie ma komputera to należy doliczyć jego koszt. Jednak dalej wyjdzie to zdecydowanie taniej niż rozpoczęcie programowania na iOS.

I jak szybko on się zwróci? Może jednak zastosować podobną miarę, jak już chcesz coś porównywać, bo od jakiegoś czasu zaczynasz mocno przeginać w stronę androida.

Jak dla mnie osoba z ulicy nie wzbogaci się na pisaniu oprogramowania na urządzenia mobilne. chyba, że zrobi na prawdę świetną aplikację i właduje do niej reklamy na których w miesiąc wyciągnie 300$. Tylko to akurat jest bardzo trudno uzyskać


Co do SDK na iOS to źle to napisałem. Założenie konta developera w Apple to 99$ - możliwość publikowania aplikacji w sklepie - nie masz alternatywy, więc jeżeli nie zapłacisz 99$ to jej nigdzie nie sprzedaż. Oczywiście nie biorę pod uwagę Cydii, która jest tylko dla urządzeń z JB.

Na Androida konto developerskie to koszt 25$. Tutaj nie musisz jednak takiego konta wykupywać. Aplikacje możesz umieścić na swojej stronie.


Wiem, że to może drobne różnice ale właśnie one decydują, że na start Android jest lepszym wyborem.

Napisany przez sobrus

Np biała linia grubości 1 piksela na czarnym tle nie da się przeskalować w dół żadnym algorytmem, aby dobrze wygladała.

Poczytaj ten link który podałem wcześniej

Co by jednak nie mówić, już te cztery podstawowe wersje to całkiem sporo.

W przypadki iOS wcale tak różowo nie ma jak by niektórzy chcieli.
http://www.mackozer.pl/2012/09/13/wi...ia-dewelopera/