Thursday, 31 March 2016

Android Build System



  • Use the daemon
    • --daemon or org.gradle.debug = true
  • Give it enough memeory
  • Control the number of threads
  • Use the latest build tools
  • Get an SSD
  • Don’t use timestamps or commit numbers in debug build files
android {
    dexOptions {
        dexInProcess = true
Consider having a development flavor using min SDK 21, as it’s going to be faster.
android.productFlavors {
    dev {
        minSdkVersion 21


Test dependencies

dependencies {
    compile ".."
    testCompile "junit:junit:4.12"
    testCompile "org.mockito:mockito-core:1.9.5"

Unit testing

unitTests.all {
    jvmArgs "-XX:MaxPermSize=256m"

    beforeTest { descriptor ->
        logger.lifecycle("Running test: " + descriptor)

Using a test project

Use a separate project just for the test APK.
In main project:
apply plugin: ''
android {
    publishNonDefault true
In test project:
apply plugin: ''
android {
    targetProjectPath ':app'
    targetVariant 'debug'

    defaultConfig {
        minSdkVersion 8
        testInstrumentationRunner ''
Test code then lives in the main source set of your test project.
Instrumentation tag still needs to be added to the test project manifest, however they’re hoping to be able to remove this step soon:
<manifest ...>
        android:targetPackage="" />
Running task on test project:
./gradlew :testProject:connectedAndroidTest
One note on all of this is to make sure that you avoid build tools and dependency version conflicts! Main APK and Test APK need to have the same Build Tools version, and same versions for dependencies. This should be common sense (since you want to test the same versions of everything).

Native Support

New plugins

  • - *.apk
  • - *.aar
  • - *.so
In build.gradle:
apply plugin: ''
model {
    android {
        compileSdkVersion = 22
        buildToolsVersion = "22.0.1"

        ndk.with {
            moduleName = "native"
            // and other configurations like the following
            stl = "stlport_static"

Inter-module dependencies

Inter-module dependencies for native code, using a library project for the native code:
apply plugin: ''
model {
    android.sources {
        main {
            jni {
                dependencies {
                    project ":lib"
Perhaps the lib project with native code is set up like this:
apply plugin: ""
model {
    android {
        compileSdkVersion = 21
    android.ndk {
        moduleName = "hello"

Extending the Android plugin


Old way:
project.afterEvaluate {
    def task = project.tasks.getByName('transformClassesWithInstantRunForDebug')
    // ...
  • not part of the official API
  • no guarantee that task names will be stable
  • no guarantee that things won’t be merged or split

Create Hello-JNI with Android Studio


2Create Java Sample App

  1. Find and start Android Studio on your development system:
  • Linux: Run from your installed location
  • OSX:  Find studio installation in Application folder, double click to start
If this is the first time you run this version of Android Studio on this system, Android Studio will prompt to import from previous settings, just select “I do not have a previous version of Studio or I do not want to import my settings”, “Welcome to Android Studio” will be displayed.
  1. Select “Start a new Android Studio project”.
  1. On “New Project” page,  change “Application Name” to HelloAndroidJni, and leave the default values for other fields.
  2. Click “Next” all the way to “Finish” to complete application creation.
    This creates an Android “Hello World” Java app; your Android Studio looks like:
  3. (Optional) Connect your Android Device with USB cable if you have device available; otherwise, create an Emulator when Android Studio prompts you in the next step.
  1. Sync , Build  and Run , you will see the following on your target device or Emulator:
  2. Configure the project to use gradle wrapper.
    a) On Mac OS, menu “Android Studio” > “Preferences”.
    b) On Linux, menu “File” > “Settings”.
    c) Then “Build, Execution, Deployment” > “Build Tools” > “Gradle”.
    d) Select “Use Default Gradle wrapper (recommended)”, click “OK”.
  1. Sync , Build  and Run , you should see the same as in step 6.

Thursday, 24 March 2016

Top 10 Most Common Mobile App Design Mistakes


The mobile app market is saturated with competition. Trends turn over quickly, but no niche can last very long without several competitors jumping onto the bandwagon. These conditions result in a high failure rate across the board for the mobile app market. Only 20% of downloaded apps see users return after the first use, whereas 3% of apps remain in use after a month.
If any part of an app is undesirable, or slow to get the hang of, users are more likely to install a new one, rather than stick it out with the imperfect product. Nothing is wasted for the consumer when disposing of an app - except for the efforts of the designers and developers, that is. So, why is it that so many apps fail? Is this a predictable phenomenon that app designers and developers should accept? For clients, is this success rate acceptable? What does it take to bring your designs into the top 3% of prosperous apps?
The common mistakes span from failing to maintain consistency throughout the lifespan of an app, to attracting users in the first place. How can apps be designed with intuitive simplicity, without becoming repetitive and boring? How can an app offer pleasing details, without losing sight of a greater purpose? Most apps live and die in the first few days, so here are the top ten most common mistakes that designers can avoid.
Only 3% of mobile apps are in use after being downloaded.
Only 3% of mobile apps are in use after being downloaded.

Common Mistake #1: A Poor First Impression

Often the first use, or first day with an app, is the most critical period to hook a potential user. The first impression is so critical that it could be an umbrella point for the rest of this top ten. If anything goes wrong, or appears confusing or boring, potential users are quickly disinterested. Although, the proper balance for first impressions is tricky to handle. In some cases, a lengthy onboarding, or process to discover necessary features can bores users. Yet, an instantly stimulating app may disregard the need for a proper tutorial, and promote confusion. Find the balance between an app that is immediately intuitive, but also introduces the users to the most exciting, engaging features quickly. Keep in mind that when users are coming to your app, they’re seeing it for the first time. Go through a proper beta testing process to learn how others perceive your app from the beginning. What seems obvious to the design team, may not be for newcomers.

Common Mistake #2: Designing an App Without Purpose

Avoid entering the design process without succinct intentions. Apps are often designed and developed in order to follow trends, rather than to solve a problem, fill a niche, or offer a distinct service. What is the ambition for the app? For the designer and their team, the sense of purpose will affect every step of a project. This sensibility will guide each decision from the branding or marketing of an app, to the wireframe format, and button aesthetic. If the purpose is clear, each piece of the app will communicate and function as a coherent whole. Therefore, have the design and development team continually consider their decisions within a greater goal. As the project progresses, the initial ambition may change. This is okay, as long as the vision remains coherent.
Conveying this vision to your potential users means that they will understand what value the app brings to their life. Thus, this vision is an important thing to communicate in a first impression. The question becomes how quickly can you convince users of your vision for the app? How it will improve a person’s life, or provide some sort of enjoyment or comfort. If this ambition is conveyed quickly, then as long as your app is in fact useful, it will make it into the 3%.
Often joining a pre-existing market, or app niche, means that there are apps to study while designing your own. Thus, be careful how you choose to ‘re-purpose’ what is already out there. Study the existing app market, rather than skimming over it. Then, improve upon existing products with intent, rather than thoughtlessly imitating.

Common Mistake #3: Missing Out On UX Design Mapping

Be careful not to skip over a thoughtful planning of an app’s UX architecture before jumping into design work. Even before getting to a wireframing stage, the flow and structure of an app should be mapped out. Designers are often too excited to produce aesthetics and details. This results in a culture of designers who generally under appreciate UX, and the necessary logic or navigation within an app. Slow down. Sketch out the flow of the app first before worrying too much about the finer brush strokes. Often apps fail from an overarching lack of flow and organization, rather than imperfect details. However, once the design process takes off always keep the big picture in mind. The details and aesthetic should then clearly evoke the greater concept.

Common Mistake #4: Disregarding App Development Budget

As soon as the basis of the app is sketched, this is a good time to get a budget from the development team. This way you don’t reach the end of the project and suddenly need to start cutting critical features. As your design career develops, always take note of the average costs of constructing your concepts so that your design thinking responds to economic restraints. Budgets should be useful design constraints to work within.

Wednesday, 2 March 2016

Image editing in android.

source :

     Image Effects:

    Android Errors: