@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:
Cytat:
|
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.
|
Cytat:
Here is a quick checklist about how you can ensure that your application displays properly on different screens:
- Use wrap_content, fill_parent, or dp units when specifying dimensions in an XML layout file
- Do not use hard coded pixel values in your application code
- Do not use AbsoluteLayout (it's deprecated)
- 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?
