How to deal with low-quality Android applications
Everyone agrees that Google Play is full of poor-quality applications, but no one wants to take the blame - it is customary to blame Android or simply Google, who released the system without strict guidelines, created a market without moderation and allowed manufacturers to make their shells with colorful icons and gradients .
But every day new applications come out with a design from iOS, themes from 2.3, not adapted for tablets and with blurry pictures on HD screens. And this is not Google’s fault, but the developers. Someone is not trying to argue when a customer sends layouts from the iOS version, someone tries, but gives up. Someone is developing an application for the sake of experience, postponing the "unimportant" for later, and so it remains. Startups make apps “for the day,” and then frantically fix bugs, creating a snowball that no one will rewrite from scratch. Large social networks, having money and time, somehow manage to release horrible customers ...
There are a lot of options, and in many of them it is impossible to correct anything or to do it initially correctly. But if at least one developer out of ten, if possible, pay attention to the details described below - 10% of new applications will become more convenient for the user.
This article is not only for beginners - many developers are well aware of the things described below, but do not pay enough attention, and someone knows Java and writes the most beautiful architecture, but does not know these little things. This article is a request to the developers from the user.
')
Very often come across applications with good functionality, but meeting the user with widgets from 2.x. The use of such applications leaves a feeling of a certain foreignness to the user. And very often this is found in the official clients of all banks and services that have no alternatives.
But to make it so that each system displays its own theme is not at all difficult. It is enough to organize a basic theme, from which the theme of the application will be inherited and redefine it for v11 + (3.0 and higher).
/res/values/styles.xml (or themes.xml):
/res/values-v11/styles.xml (or themes.xml):
/AndroidManifest.xml:
This was described in the developers blog a long time ago, but applications with outdated designs continue to appear.
Many people think that the Action Bar pattern is just the title of the window with icons and did not even read the official documentation .
Even if all the functionality of the Action Bar in your application comes down to the window title - still use ActioBarSherlock . Having written a homemade title - you will not then add support for the menu, control the visibility of icons and their signatures with different screen sizes, split view for small screens, a loading indicator, and other features.
ActionBarSherlock uses the native Action Bar for ICS and higher, and ports all the functionality for versions that do not support it, or partially support it. A demo of all the possibilities is here .
Starting to use it is very simple:
In many projects, support for tablets is postponed until later, as something special and additional. Although in fact, an Android application should be initially responsive and not distinguish between phones and tablets. For an application, these are simply devices with different screen sizes and it should be as user-friendly as possible to fill these screens.
Even if there is no time for rewriting via FragmentManager, or it is extremely difficult in the existing architecture - you can take the code from the Activity into fragments and organize the simplest support for tablets.
For example, you have an already implemented application with two windows - a list and a detailed view.
After such simple manipulations, we get excellent markup for a large screen:
Very often there are applications in which even the simplest gradient is implemented using stretched png. And when there is a lot of such graphics on the screen - the reasons for the brakes start to look in the application logic.
Even if another designer sent another raster layout from Photoshop, made on iOS guidelines - before you cut it all into pictures, think about each element:
An excellent editor for Nine Patch is here - http://habrahabr.ru/company/alee/blog/136667/ . And do not forget that the creation of graphic resources for xhdpi, hdpi, mdpi also applies to the nine-patch. You should not shift this work to the user device.
Someone will say that all this is not necessary, because the average user does not know where the new one is, and where the outdated interface is, and most do not know where TouchWiz ends and Android begins ... But if you do everything as it is, because Google does not prohibit and the customer does not understand - Google Play will continue to be filled with low-quality applications, which “analysts” will continue to write about. And as a result - development for Android is less profitable than for iOS.
Of course, I simplify everything and exaggerate - but I want to instill some responsibility in the developers.
But every day new applications come out with a design from iOS, themes from 2.3, not adapted for tablets and with blurry pictures on HD screens. And this is not Google’s fault, but the developers. Someone is not trying to argue when a customer sends layouts from the iOS version, someone tries, but gives up. Someone is developing an application for the sake of experience, postponing the "unimportant" for later, and so it remains. Startups make apps “for the day,” and then frantically fix bugs, creating a snowball that no one will rewrite from scratch. Large social networks, having money and time, somehow manage to release horrible customers ...
There are a lot of options, and in many of them it is impossible to correct anything or to do it initially correctly. But if at least one developer out of ten, if possible, pay attention to the details described below - 10% of new applications will become more convenient for the user.
This article is not only for beginners - many developers are well aware of the things described below, but do not pay enough attention, and someone knows Java and writes the most beautiful architecture, but does not know these little things. This article is a request to the developers from the user.
')
Please use holo
Very often come across applications with good functionality, but meeting the user with widgets from 2.x. The use of such applications leaves a feeling of a certain foreignness to the user. And very often this is found in the official clients of all banks and services that have no alternatives.
But to make it so that each system displays its own theme is not at all difficult. It is enough to organize a basic theme, from which the theme of the application will be inherited and redefine it for v11 + (3.0 and higher).
/res/values/styles.xml (or themes.xml):
<resources> <style name="BaseTheme" parent="@android:style/Theme"> <!-- 3.0 --> </style> <style name="MyTheme" parent="BaseTheme"> <!-- --> </style> </resources> /res/values-v11/styles.xml (or themes.xml):
<resources> <style name="BaseTheme" parent="@android:style/Theme.Holo"> <!-- 3.0 --> </style> </resources> /AndroidManifest.xml:
<!-- [...] --> <application android:name="MyApplication" android:label="@string/application_label" android:icon="@drawable/app_icon" android:hardwareAccelerated="true" android:theme="@style/MyTheme"> <!-- [...] --> This was described in the developers blog a long time ago, but applications with outdated designs continue to appear.
Please use ActionBarSherlock
Many people think that the Action Bar pattern is just the title of the window with icons and did not even read the official documentation .
Even if all the functionality of the Action Bar in your application comes down to the window title - still use ActioBarSherlock . Having written a homemade title - you will not then add support for the menu, control the visibility of icons and their signatures with different screen sizes, split view for small screens, a loading indicator, and other features.
ActionBarSherlock uses the native Action Bar for ICS and higher, and ports all the functionality for versions that do not support it, or partially support it. A demo of all the possibilities is here .
Starting to use it is very simple:
- Add a project as a library to your application.
- Tweak themes for older API versions to use Theme.Sherlock.xxx as the base
- Inherit Activity from SherlockActivity or SherlockFragmentActivity
- And you can communicate with Action Bar via getSupportActionBar ()
Please use fragments
In many projects, support for tablets is postponed until later, as something special and additional. Although in fact, an Android application should be initially responsive and not distinguish between phones and tablets. For an application, these are simply devices with different screen sizes and it should be as user-friendly as possible to fill these screens.
Even if there is no time for rewriting via FragmentManager, or it is extremely difficult in the existing architecture - you can take the code from the Activity into fragments and organize the simplest support for tablets.
For example, you have an already implemented application with two windows - a list and a detailed view.
- We take out the code in two fragments
- Insert these fragments into the Activity via markup:
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools" xmlns:app="http://schemas.android.com/apk/res-auto" android:layout_width="match_parent" android:layout_height="match_parent" > <fragment android:id="@+id/SomeFragment" android:layout_width="match_parent" android:layout_height="match_parent" class="com.example.SomeFragment"/> </LinearLayout> - We create special markup for screens, for example, a length greater than 800dp:
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools" xmlns:app="http://schemas.android.com/apk/res-auto" android:layout_width="match_parent" android:layout_height="match_parent" android:orientation="horizontal" > <fragment android:id="@+id/listFragment" android:layout_width="400dp" android:layout_height="fill_parent" class="com.example.ListFragment" /> <View android:layout_width="10dp" android:layout_height="fill_parent" android:background="@color/FragmentDivider" > </View> <fragment android:id="@+id/detailsFragment" android:layout_width="match_parent" android:layout_height="match_parent" class="com.example.DetailsFragment"/> </LinearLayout> - When you click on the list item, we check if there is a second fragment. If there is - update its contents, if not - then we are on a small screen and you need to start activating.
... if (getActivity().findViewById(R.id.listsFragment) != null) { // ListFragment fragment = (ListFragment) getActivity().getSupportFragmentManager().findFragmentById(R.id.listsFragment); fragment.setDetails(...); } else { // ... } ...
After such simple manipulations, we get excellent markup for a large screen:
Please try to use xml and nine-patch for graphics.
Very often there are applications in which even the simplest gradient is implemented using stretched png. And when there is a lot of such graphics on the screen - the reasons for the brakes start to look in the application logic.
Even if another designer sent another raster layout from Photoshop, made on iOS guidelines - before you cut it all into pictures, think about each element:
- Can this be done with simple primitives, fills, gradients and rounded corners in XML?
- Can I do this with Nine Patch?
An excellent editor for Nine Patch is here - http://habrahabr.ru/company/alee/blog/136667/ . And do not forget that the creation of graphic resources for xhdpi, hdpi, mdpi also applies to the nine-patch. You should not shift this work to the user device.
Conclusion
Someone will say that all this is not necessary, because the average user does not know where the new one is, and where the outdated interface is, and most do not know where TouchWiz ends and Android begins ... But if you do everything as it is, because Google does not prohibit and the customer does not understand - Google Play will continue to be filled with low-quality applications, which “analysts” will continue to write about. And as a result - development for Android is less profitable than for iOS.
Of course, I simplify everything and exaggerate - but I want to instill some responsibility in the developers.
Source: https://habr.com/ru/post/178673/
All Articles