Is it possible to use Actionbar on Android natively?

Asked

Viewed 934 times

3

I’m doing some test applications and I ended up coming across something that has caused me many doubts, the Android support libraries. I tried to develop an application that uses Actionbar natively (without support), works perfectly on the emulator, but when I try on my smartphone, the menu item that is with android:showAsAction="never" is not displayed, follow the settings and the code I have.

Note: in the emulator the entry with android:showAsAction="never" appears within the three dots.

Emulator: Android Lollipop (API 21)
Smartphone: Android Kitkat (API 19)

Mainactivity.java

import android.app.Activity;
import android.os.Bundle;
import android.view.Menu;
import android.view.MenuInflater;
import android.view.MenuItem;
import android.widget.Toast;

public class MainActivity extends Activity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.layout);
    }

    @Override
    public boolean onCreateOptionsMenu(Menu menu) {
        MenuInflater inflater = getMenuInflater();
        inflater.inflate(R.menu.menu, menu);
        return super.onCreateOptionsMenu(menu);
    }

    @Override
    public boolean onOptionsItemSelected(MenuItem item) {
        switch (item.getItemId()) {
            case R.id.action_1:
                Toast.makeText(this, "Você clicou em procurar.", Toast.LENGTH_LONG).show();
                return true;
            case R.id.action_2:
                Toast.makeText(this, "Você clicou em editar.", Toast.LENGTH_LONG).show();
                return true;
            default:
                return super.onOptionsItemSelected(item);
        }
    }
}

xml menu.

<menu xmlns:android="http://schemas.android.com/apk/res/android">
    <item
        android:id="@+id/action_1"
        android:icon="@android:drawable/ic_menu_search"
        android:showAsAction="ifRoom"
        android:title="Procurar" />

    <item
        android:id="@+id/action_2"
        android:showAsAction="never"
        android:title="Editar" />
</menu>

build.Gradle

apply plugin: 'com.android.application'

android {
    compileSdkVersion 21
    buildToolsVersion "21.1.2"

    defaultConfig {
        applicationId "br.com.exemplo.myapplication"
        minSdkVersion 15
        targetSdkVersion 21
        versionCode 1
        versionName "1.0"
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
}

Androidmanifest.xml

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="br.com.exemplo.myapplication">

    <application
        android:allowBackup="true"
        android:icon="@drawable/ic_launcher"
        android:label="@string/app_name"
        android:theme="@style/AppTheme">
        <activity android:name=".MainActivity">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>

    </application>

</manifest>

Styles.xml

<resources>

    <style name="AppTheme" parent="android:Theme.Holo.Light" />

</resources>

Following that link from the OS I was able to do it with the support library, but I noticed the size of the .apk from 53.6 KB (no support) to 0.9 MB (with support) and the smartphone space used was 72 KB (no support) to more than 3 MB (with support). So my doubts are as follows:

  • It is possible to make an application use Actionbar without the support library (for devices with API 15 or higher)?
  • When I should really use the support libraries?

Extra

The Actionbar Apis Were first Added in Android 3.0 (API level 11) but they are also available in the Support Library for Compatibility with Android 2.1 (API level 7) and above.

According to this section above, theoretically the Actionbar should be native from API 11 or am I confusing different subjects?

2 answers

5


Actionbar can be used natively, remembering that Actionbar is the entire bar and not just the menu.

I believe that the problem encountered is the presence of a physical menu on your device, is just a kick. In the case of ActionBar of the support library, it uses the ActionBar native. But the difference is who implements the organization of the menus, which in the case of Support Library is itself, there may be some difference in the end result.

In the case of the native menu, when you have a physical menu, overflow menu (three dots) is hidden, having to press the physical menu for the options appear (http://developer.android.com/design/patterns/compatibility.html). This occurs to cause no ambiguity (two ways of doing the same thing).

You can use this hack to force the appearance, but it is not recommended as it is good to maintain consistency with other applications.

try {
    ViewConfiguration config = ViewConfiguration.get(this);
    Field menuKeyField = ViewConfiguration.class.getDeclaredField("sHasPermanentMenuKey");

    if (menuKeyField != null) {
        menuKeyField.setAccessible(true);
        menuKeyField.setBoolean(config, false);
    }
} catch (Exception e) {}

Sources:

Currently Actionbar is going into disuse, in favor of the Toolbar. The Toolbar is a generalization of ActionBar by allowing a generic positioning, greater control and a greater power of stylization in various aspects, in the special case it plays the role of ActionBar.

In addition it came with great force because of the Material Design, which features some topics on it in Guideline: http://www.google.com/design/spec/layout/structure.html#Structure-toolbars and http://www.google.com/design/spec/layout/principles.html#.

It appeared in version 21, but the support library itself implements it to lower versions. If you want to see how to use it: How to use the Toolbar widget?.


The support library has many more features than just the ActionBar/Toolbar, it is good to take a look at the features: http://developer.android.com/tools/support-library/features.html.

Recalling that are several modules almost independent:

  • Support Library v4
  • Support Library v7 (depends on Support Library v4):

    • Appcompat
    • Gridlayout
    • Media-router
    • Cardview
    • Palette
    • Recyclerview
  • Support Library V8

  • Support Library v13

In fact, as the support library is very extensive in functionality, it ends up weighing. It is worth evaluating if this "cost" compensates in relation to the benefit you will have. Remembering that the vast majority (I don’t have statistical data, it’s just a conjecture) of applications have much larger sizes (because they use many other libraries).

A cool app to check this is the Detective Droid, which lists which libraries a particular application has.

In my opinion, it is almost time to start ignoring certain versions. According to the Dashboard, there are only 7.4% of the devices with Gingerbread. It’s a small number but I don’t know if it could be ignored right now, but soon.

Only this statistic would lead to the abandonment of Support Libraries, but sometimes the implementation that it makes of various functionalities are much more stable than the native ones, which do not suffer corrections, unlike the Support Library. This can be seen in the list of revisions: http://developer.android.com/tools/support-library/index.html.

I think this post: https://stackoverflow.com/questions/17295497/fragment-or-support-fragment already cites a problem faced with the Fragment's natives.

  • Really that’s it, not aware of this detail of the physical button, the emulator probably does not have this setting enabled (if that is possible).

0

Beyond what @Wakim said:

If you don’t use the compatibility libraries, you’ll see that your app might look slightly different depending on the Android version and the device manufacturer. Using the Holo theme, you will get an app with "old" face, without using the Material Design. Depending on your target audience, this can have a big impact.

Also, search for proguard (https://developer.android.com/tools/help/proguard.html). It decreases the final apk and application size after installation. You can activate it in the "minifyEnabled" command of your build.gradle. You can find in Google a configuration that optimizes for the support libraries, but Androidstudio already provides a basic.

By default, Gradle only executes proguard when you build apk for publication (buildTypes > release > minifyEnabled), because it takes time to execute.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.