Elite Technority: asset

Showing posts with label asset. Show all posts

Tuesday, 15 August 2017

HB Blog 142: Android Configure Using Build Variants - Part 2.

Hello friends, Thanks for reading my previous post on HB Blog 141: Android Configure Build Variants - Part 1.

This post will show you how you can configure build variants to create different versions of your app from a single project, and how to properly manage your dependencies and signing configurations.

Build variants are the result of Gradle using a specific set of rules to combine settings, code, and resources configured in your build types and product flavors. Although you do not configure build variants directly, you do configure the build types and product flavors that form them. Each build variant represents a different version of your app that you can build. For example, you might want to build one version of your app that's free, with a limited set of content, and another paid version that includes more. You can also build different versions of your app that target different devices, based on API level or other device variations.

Refer the below link for complete sample code:-

Download Sample Code

Have a look on few code snippets,

//build.gradle

apply plugin: 'com.android.application'

android {
    compileSdkVersion 25
    buildToolsVersion "25.0.2"
    defaultConfig {
        applicationId "com.harshalbenake.buildvariant"
        minSdkVersion 15
        targetSdkVersion 25
        versionCode 1
        versionName "1.0"
    }

    /**
     * The following sample specifies an applicationIdSuffix for the debug build type,
     * and configures a "jnidebug" build type that is initialized using settings from
     * the debug build type.
     */
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }

        debug {
            applicationIdSuffix ".debug"
        }

        /**
         * The 'initWith' property allows you to copy configurations from other build types,
         * so you don't have to configure one from the beginning. You can then configure
         * just the settings you want to change. The following line initializes
         * 'jnidebug' using the debug build type, and changes only the
         * applicationIdSuffix and versionNameSuffix settings.
         */
        jnidebug {
            // This copies the debuggable attribute and debug signing configurations.
            initWith debug

            applicationIdSuffix ".jnidebug"
            jniDebuggable true
        }
    }

    // Specifies the flavor dimensions you want to use. The order in which you
    // list each dimension determines its priority, from highest to lowest,
    // when Gradle merges variant sources and configurations. You must assign
    // each product flavor you configure to one of the flavor dimensions.
    flavorDimensions "api", "mode"

    /**
     * The following code sample creates "demo" and "full" product flavors
     * which provide their own applicationIdSuffix and versionNameSuffix.
     * The following code sample uses the flavorDimensions property
     * to create a "mode" flavor dimension to group the "full" and "demo" product flavors,
     * and an "api" flavor dimension to group product flavor configurations based on API level
     */
    productFlavors {
        demo {
            applicationIdSuffix ".demo"
            versionNameSuffix "-demo"
            // Assigns this product flavor to the "mode" flavor dimension.
            dimension "mode"
            resValue "string", "app_name", "HB Demo"
        }
        full {
            applicationIdSuffix ".full"
            versionNameSuffix "-full"
            dimension "mode"
            resValue "string", "app_name", "HB Full"
        }

        // Configurations in the "api" product flavors override those in "mode"
        // flavors and the defaultConfig block. Gradle determines the priority
        // between flavor dimensions based on the order in which they appear next
        // to the flavorDimensions property above--the first dimension has a higher
        // priority than the second, and so on.
        minApi24 {
            dimension "api"
            minSdkVersion '24'
            // To ensure the target device receives the version of the app with
            // the highest compatible API level, assign version codes in increasing
            // value with API level. To learn more about assigning version codes to
            // support app updates and uploading to Google Play, read Multiple APK Support
            versionCode 30000 + android.defaultConfig.versionCode
            versionNameSuffix "-minApi24"
        }

        minApi23 {
            dimension "api"
            minSdkVersion '23'
            versionCode 20000  + android.defaultConfig.versionCode
            versionNameSuffix "-minApi23"
        }

        minApi21 {
            dimension "api"
            minSdkVersion '21'
            versionCode 10000 + android.defaultConfig.versionCode
            versionNameSuffix "-minApi21"
        }
}

    /**
     * Using the build configuration from the previous section as an example,
     * suppose you plan to support only API levels 23 and higher for the demo version of the app.
     * You can use the variantFilter block to filter out all build variant configurations that
     * combine the "minApi21" and "demo" product flavors.
     */
    variantFilter { variant ->
        def names = variant.flavors*.name
        // To check for a certain build type, use variant.buildType.name == "<buildType>"
        if (names.contains("minApi23") && names.contains("full")) {
            // Gradle ignores any variants that satisfy the conditions above.
            setIgnore(true)
        }
    }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:appcompat-v7:25.3.1'
}

Tuesday, 1 August 2017

HB Blog 141: Android Configure Using Build Variants - Part 1.

The Android build system compiles app resources and source code, and packages them into an Android Application Package (APK), that you can test, deploy, sign, and distribute. Android Studio uses Gradle, an advanced build toolkit, to automate and manage the build process, while allowing you to define flexible custom build configurations.

The build process for a typical Android app module follows these general steps:

The compilers convert your source code into DEX (Dalvik Executable) files, which include the bytecode that runs on Android devices, and everything else into compiled resources.
The APK Packager combines the DEX files and compiled resources into a single APK. Before your app can be installed and deployed onto an Android device, however, the APK must be signed.
Before generating your final APK, the packager uses the zipalign tool to optimize your app to use less memory when running on a device.

At the end of the build process, you have either a debug APK or release APK of your app that you can use to deploy, test, or release to external users.

For more details, visit my post HB Blog 51: Android Build System - How Android Apk Is Built.

Gradle and the Android plugin help you configure the following aspects of your build:

Build Types :-
    Build types define certain properties that Gradle uses when building and packaging your app, and are typically configured for different stages of your development lifecycle. For example, the debug build type enables debug options and signs the APK with the debug key, while the release build type may shrink, obfuscate, and sign your APK with a release key for distribution. You must define at least one build type in order to build your app—Android Studio creates the debug and release build types by default.

Product Flavors :-
    Product flavors represent different versions of your app that you may release to users, such as free and paid versions of your app. You can customize product flavors to use different code and resources, while sharing and reusing the parts that are common to all versions of your app. Product flavors are optional and you must create them manually.

Build Variants :-
    A build variant is a cross product of a build type and product flavor, and is the configuration Gradle uses to build your app. Using build variants, you can build the debug version of your product flavors during development, or signed release versions of your product flavors for distribution. Although you do not configure build variants directly, you do configure the build types and product flavors that form them. Creating additional build types or product flavors also creates additional build variants.

Manifest Entries :-
    You can specify values for some properties of the manifest file in the build variant configuration. These build values override the existing values in the manifest file. This is useful if you want to generate multiple APKs for your modules where each of the apk files has a different application name, minimum SDK version, or target SDK version.

Dependencies :-
    The build system manages project dependencies from your local filesystem and from remote repositories. This prevents you from having to manually search, download, and copy binary packages of your dependencies into your project directory.

Signing :-
    The build system enables you to specify signing settings in the build configuration, and it can automatically sign your APKs during the build process. The build system signs the debug version with a default key and certificate using known credentials to avoid a password prompt at build time. The build system does not sign the release version unless you explicitly define a signing configuration for this build.
For more details, visit my post, HB Blog 120: How To Sign Your APKs Using Android Studio.

ProGuard :-
    The build system enables you to specify a different ProGuard rules file for each build variant. The build system can run ProGuard to shrink and obfuscate your classes during the build process.
For more details, visit my post, HB Blog 139: ProGuard - Shrinks, Optimizes, And Obfuscates Your Code.

Multiple APK Support :-
    The build system enables you to automatically build different APKs that each contain only the code and resources needed for a specific screen density or Application Binary Interface (ABI).

Custom Build Configurations :-

Creating custom build configurations requires you to make changes to one or more build configuration files, or build.gradle files. These plain text files use Domain Specific Language (DSL) to describe and manipulate the build logic using Groovy, which is a dynamic language for the Java Virtual Machine (JVM).

When starting a new project, Android Studio automatically creates some of these files for you, as shown in below image, and populates them based on sensible defaults.

......Continue, to read more on Build Variant gradle in my next post, Android Configure Using Build Variants - Part 2.

Friday, 19 May 2017

HB Blog 136: Android Automation Testing Using Espresso Framework.

Android tests are based on JUnit, and you can run them either as local unit tests on the JVM or as instrumented tests on an Android device. This post provides an introduction to the concepts and tools for building Android tests.
When using Android Studio to write any of your tests, your test code must go into one of two different code directories (source sets). For each module in your project, Android Studio includes both source sets, corresponding to the following test types:

Local unit tests:-
Located at module-name/src/test/java/.
These tests run on the local JVM and do not have access to functional Android framework APIs.

Instrumented tests:-
Located at module-name/src/androidTest/java/.
These are all tests that must run on an Android hardware device or an Android emulator.
Instrumented tests are built into an APK that runs on the device alongside your app under test. The system runs your test APK and your app under tests in the same process, so your tests can invoke methods and modify fields in the app, and automate user interaction with your app.
        Building Instrumented Unit Tests: Build complex unit tests with Android dependencies that cannot be satisfied with mock objects.
        Automating User Interface Tests: Create tests to verify that the user interface behaves correctly for user interactions within a single app or for interactions across multiple apps.
        Testing App Component Integrations: Verify the behavior of components that users do not directly interact with, such as a Service or a Content Provider.

However, the local unit tests and instrumented tests described above are just terms that help distinguish the tests that run on your local JVM from the tests that run on the Android platform (on a hardware device or emulator). The real testing types that you should understand when building a complete test suite are described in the following table.

Type	Subtype	Description
Unit tests
	Local Unit Tests	Unit tests that run locally on the Java Virtual Machine (JVM). Use these tests to minimize execution time when your tests have no Android framework dependencies or when you can mock the Android framework dependencies.
	Instrumented unit tests	Unit tests that run on an Android device or emulator. These tests have access to `Instrumentation` information, such as the `Context` of the app you are testing. Use these tests when your tests have Android dependencies that mock objects cannot satisfy.
Integration Tests
	Components within your app only	This type of test verifies that the target app behaves as expected when a user performs a specific action or enters a specific input in its activities. For example, it allows you to check that the target app returns the correct UI output in response to user interactions in the app’s activities. UI testing frameworks like Espresso allow you to programmatically simulate user actions and test complex intra-app user interactions.
	Cross-app Components	This type of test verifies the correct behavior of interactions between different user apps or between user apps and system apps. For example, you might want to test that your app behaves correctly when the user performs an action in the Android Settings menu. UI testing frameworks that support cross-app interactions, such as UI Automator, allow you to create tests for such scenarios.

JUnit
You should write your unit or integration test class as a JUnit test class. The framework offers a convenient way to perform common setup, teardown, and assertion operations in your test.
A basic JUnit test class is a Java class that contains one or more test methods. A test method begins with the @Test annotation and contains the code to exercise and verify a single functionality (that is, a logical unit) in the component that you want to test.
The following snippet shows an example JUnit integration test that uses the Espresso APIs to perform a click action on a UI element, then checks to see if an expected string is displayed.

@RunWith(AndroidJUnit4.class)
@LargeTest
public class MainActivityInstrumentationTest {

    @Rule
    public ActivityTestRule mActivityRule = new ActivityTestRule<>(
            MainActivity.class);

    @Test
    public void sayHello(){
        onView(withText("Say hello!")).perform(click());

        onView(withId(R.id.textView)).check(matches(withText("Hello, World!")));
    }
}

In your JUnit 4 test class, you can call out sections in your test code for special processing by using the following annotations:

@Before: Use this annotation to specify a block of code that contains test setup operations. The test class invokes this code block before each test. You can have multiple @Before methods but the order in which the test class calls these methods is not guaranteed.
@After: This annotation specifies a block of code that contains test tear-down operations. The test class calls this code block after every test method. You can define multiple @After operations in your test code. Use this annotation to release any resources from memory.
@Test: Use this annotation to mark a test method. A single test class can contain multiple test methods, each prefixed with this annotation.
@Rule: Rules allow you to flexibly add or redefine the behavior of each test method in a reusable way. In Android testing, use this annotation together with one of the test rule classes that the Android Testing Support Library provides, such as ActivityTestRule or ServiceTestRule.
@BeforeClass: Use this annotation to specify static methods for each test class to invoke only once. This testing step is useful for expensive operations such as connecting to a database.
@AfterClass: Use this annotation to specify static methods for the test class to invoke only after all tests in the class have run. This testing step is useful for releasing any resources allocated in the @BeforeClass block.
@Test(timeout=): Some annotations support the ability to pass in elements for which you can set values. For example, you can specify a timeout period for the test. If the test starts but does not complete within the given timeout period, it automatically fails. You must specify the timeout period in milliseconds, for example: @Test(timeout=5000).

Use the JUnit Assert class to verify the correctness of an object's state. The assert methods compare values you expect from a test to the actual results and throw an exception if the comparison fails. Assertion classes describes these methods in more detail.

Tuesday, 15 November 2016

HB Blog 123: Android PowerPoint Viewer Tutorial.

Microsoft PowerPoint is a slide show presentation program currently developed by Microsoft, for use on both Microsoft and Apple Macintosh operating systems. PowerPoint, initially named "Presenter", was created by Forethought Inc.. Microsoft's version of PowerPoint was officially launched on May 22, 1990, as a part of the Microsoft Office suite. PowerPoint is useful for helping develop the slide-based presentation format and is currently one of the most commonly used slide-based presentation programs available. Microsoft has also released the PowerPoint mobile application for use on Apple and Android mobile operating systems.

PowerPoint presentations consist of a number of individual pages or "slides". The "slide" analogy is a reference to the slide projector. Slides may contain text, graphics, sound, movies, and other objects, which may be arranged freely.

Microsoft Office PowerPoint Viewer is a program used to run presentations on computers that do not have PowerPoint installed. Office PowerPoint Viewer (or in PowerPoint 2007 and later, a link to a viewer download) is added by default to the same disk or network location that contains one or more presentations packaged by using the Package for CD feature. PowerPoint Viewer is installed by default with a Microsoft Office 2003 installation for use with the Package for CD feature. The PowerPoint Viewer file is also available for download from the Microsoft Office Online Web site. Presentations password-protected for opening or modifying can be opened by PowerPoint Viewer. The Package for CD feature allows packaging any password-protected file or setting a new password for all packaged presentations. PowerPoint Viewer prompts for a password if the file is open password-protected. PowerPoint Viewer supports opening presentations created using PowerPoint 97 and later. In addition, it supports all file content except OLE objects and scripting. PowerPoint Viewer is currently only available for computers running on Microsoft Windows.

For Android mobile platform OS we have itsrts-pptviewer.jar library which acts as PowerPoint Viewer in the Android application,

Refer the below link for complete sample code:-

Download Sample Code

Have a look on few code snippets,

activity_main.xml

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent">
    <com.itsrts.pptviewer.PPTViewer
        android:id="@+id/pptviewer"
        android:layout_width="match_parent"
        android:layout_height="match_parent" />
</RelativeLayout>

MainActivity.java

package com.example.harshalbenake.pptviewer;

import android.app.Activity;
import android.os.Bundle;
import android.os.Environment;
import com.itsrts.pptviewer.PPTViewer;

public class MainActivity extends Activity {
    PPTViewer pptViewer;
    public static final String sdCardPath = Environment.getExternalStorageDirectory() + "/";

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        pptViewer = (PPTViewer) findViewById(R.id.pptviewer);
        String path = sdCardPath +"Bestowal" + "/" + "PPT1.ppt";
        pptViewer.setNext_img(R.drawable.next).setPrev_img(R.drawable.prev)
                .setSettings_img(R.drawable.settings)
                .setZoomin_img(R.drawable.zoomin)
                .setZoomout_img(R.drawable.zoomout);
        pptViewer.loadPPT(this, path);
    }
}

Saturday, 2 January 2016

HB Blog 101: Vector Drawables - SVG To XML.

In Android development, and similar other mobile application development we observe that user interface and user experience plays the most vital roles. Specifically, in Android we have drawable making the application attractive. But, we also see that the drawable should be maintained for different densities, which eventually increases the size of the Apk as well as the application can become heavy.

Android came with the concept of vector drawable replacing old .png images with .xml vectors. These vector images are not only light weight but also gives more clear user interface for icons.
This lets you create a drawable based on an XML vector graphic. It can be defined in an XML file with the <vector> element.

Here is a simple VectorDrawable in this vectordrawable.xml file.

//vectordrawable.xml

 <vector xmlns:android="http://schemas.android.com/apk/res/android"

     android:height="64dp"

     android:width="64dp"

     android:viewportHeight="600"

     android:viewportWidth="600" >

     <group

         android:name="rotationGroup"

         android:pivotX="300.0"

         android:pivotY="300.0"

         android:rotation="45.0" >

         <path

             android:name="v"

             android:fillColor="#000000"

             android:pathData="M300,70 l 0,-70 70,70 0,0 -70,70z" />

     </group>

 </vector>

Tuesday, 11 August 2015

HB Blog 89: UI/UX Images With Appropriate Sizes And Resolutuons In Android And iOS.

Mobile technology is growing at a very pace, and mobile technology and applications attract user with its UI/UX. The user interface(UI) is one of the most important parts of any program because it determines how easily you can make the program do what you want. A powerful program with a poorly designed user interface has little value. User experience design (UXD or UED) is the process of enhancing user satisfaction by improving the usability, accessibility, and pleasure provided in the interaction between the user and the product. User experience design encompasses traditional human–computer interaction (HCI) design, and extends it by addressing all aspects of a product or service as perceived by users. UI and UX in mobile applications are depended on images that the application is developed with. It includes appropriate sizes, colors, resolutions, density, etc.

There is a standard used for specific images for place where image is to be used with appropriate sizes and resolutions. In Android, below table explains the sizes and resolutions for the different types of icons used by applications.

	MDPI (Baseline)	HDPI	XHDPI	XXHDPI	XXXHDPI
Scale	1 x	1.5 x	2 x	3 x	4 x
DPI	~ 160 dpi	~ 240 dpi	~ 320 dpi	~ 480 dpi	~ 640 dpi
App Launcher Icons	48 px	72 px	96 px	144 px	192 px
Action bar Icons	32 px (24px inset)	48 px	64 px	96 px	128 px
Small / Contextual Icons	16 px (12px inset)	24 px	32 px	48 px	64 px
Notification Icons	24 px (22px inset)	36 px	48 px	72 px	96 px

In iOS, below table explains the sizes and resolutions for the different types of icons used by applications.

Asset	iPhone 6 Plus (@3x)	iPhone 6 and iPhone 5 (@2x)	iPhone 4s (@2x)	iPad and iPad mini (@2x)	iPad 2 and iPad mini (@1x)
App icon (required for all apps)	180 x 180	120 x 120	120 x 120	152 x 152	76 x 76
App icon for the App Store (required for all apps)	1024 x 1024	1024 x 1024	1024 x 1024	1024 x 1024	1024 x 1024
Launch file or image (required for all apps)	Use a launch file (see Launch Images)	For iPhone 6, use a launch file (see Launch Images) For iPhone 5, 640 x 1136	640 x 960	1536 x 2048 (portrait) 2048 x 1536 (landscape)	768 x 1024 (portrait) 1024 x 768 (landscape)
Spotlight search results icon (recommended)	120 x 120	80 x 80	80 x 80	80 x 80	40 x 40
Settings icon (recommended)	87 x 87	58 x 58	58 x 58	58 x 58	29 x 29
Toolbar and navigation bar icon (optional)	About 66 x 66	About 44 x 44	About 44 x 44	About 44 x 44	About 22 x 22
Tab bar icon (optional)	About 75 x 75 (maximum: 144 x 96)	About 50 x 50 (maximum: 96 x 64)	About 50 x 50 (maximum: 96 x 64)	About 50 x 50 (maximum: 96 x 64)	About 25 x 25 (maximum: 48 x 32)
Default Newsstand cover icon for the App Store (required for Newsstand apps)	At least 1024 pixels on the longest edge	At least 1024 pixels on the longest edge	At least 1024 pixels on the longest edge	At least 1024 pixels on the longest edge	At least 512 pixels on the longest edge
Web clip icon (recommended for web apps and websites)	180 x 180	120 x 120	120 x 120	152 x 152	76 x 76

Thursday, 6 November 2014

HB Blog 33: How To Access Database From Asset Folder In Android.

In this post, I will show how to access sqlite database from asset folder in android.
We just need to create a new project and keep our desire sqlite databasein asset folder.Then, using simple code we will first copy the database into sd card and you can use database as normally by firing queries.

Have a look on few code snippets,

DataBaseHelper.java

//Copies your database from your local assets-folder to the just created empty database in the system folder
    private void copyDataBase() throws IOException
    {
          String outFileName = DATABASE_PATH + DATABASE_NAME;
          OutputStream myOutput = new FileOutputStream(outFileName);
          InputStream myInput = myContext.getAssets().open(DATABASE_NAME);
          byte[] buffer = new byte[1024];
          int length;
          while ((length = myInput.read(buffer)) > 0){
                myOutput.write(buffer, 0, length);
          }
          myInput.close();
          myOutput.flush();
          myOutput.close();
    }

Refer the below link for complete sample code:-
Download Sample Code

Download Apk File