Android Development – Good Quick Tips

You can download file with more description : – > ANDROID_USEFUL_TIPS


Android SDK

Place your Android SDK somewhere in your home directory or some other application-independent location. Some IDEs include the SDK when installed, and may place it under the same directory as the IDE. This can be bad when you need to upgrade (or reinstall) the IDE, or when changing IDEs. Also avoid putting the SDK in another system-level directory that might need sudo permissions, if your IDE is running under your user and not under root.

Project structure

There are two popular options: the old Ant & Eclipse ADT project structure, and the new Gradle & Android Studio project structure. You should choose the new project structure. If your project uses the old structure, consider it legacy and start porting it to the new structure.
Old structure:
├─ assets
├─ libs
├─ res
├─ src
│ └─ com/futurice/project
├─ AndroidManifest.xml
├─ build.gradle
New structure:
├─ library-foobar
├─ app
│ ├─ libs
│ ├─ src
│ │ ├─ androidTest
│ │ │ └─ java
│ │ │ └─ com/futurice/project
│ │ └─ main
│ │ ├─ java
│ │ │ └─ com/futurice/project
│ │ ├─ res
│ │ └─ AndroidManifest.xml
│ ├─ build.gradle
│ └─
├─ build.gradle
└─ settings.gradle
The main difference is that the new structure explicitly separates ‘source sets’ (main, androidTest), a concept from Gradle. You could, for instance, add source sets ‘paid’ and ‘free’ into src which will have source code for the paid and free flavours of your app.
Having a top-level app is useful to distinguish your app from other library projects (e.g., library-foobar) that will be referenced in your app. The settings.gradle then keeps references to these library projects, which app/build.gradlecan reference to.

There are short list with useful tips:

      Use Gradle and its recommended project structure


      Put passwords and sensitive data in


      Use the Jackson library to parse JSON data


      Don’t write your own HTTP client, use Volley or OkHttp libraries


      Avoid Guava and use only a few libraries due to the 65k method limit


      Use Fragments to represent a UI screen


      Use Activities just to manage Fragments


      Layout XMLs are code, organize them well


      Use styles to avoid duplicate attributes in layout XMLs


      Use multiple style files to avoid a single huge one


      Keep your colors.xml short and DRY, just define the palette


      Also keep dimens.xml DRY, define generic constants


      Do not make a deep hierarchy of ViewGroups


      Avoid client-side processing for WebViews, and beware of leaks


      Use Robolectric for unit tests, Robotium for connected (UI) tests


      Use Genymotion as your emulator


      Always use ProGuard or DexGuard


      Use SharedPreferences for simple persistence, otherwise ContentProviders


    Use Stetho to debug your application

Leave a Reply

Your email address will not be published. Required fields are marked *