Beauty Me Case Study: Android Powered By Studio

Beauty Me Case Study: Android Powered By Studio

In previous post, we had talked about iOS app of Beauty Me project. We had used XCode with new and shiny language Swift to provide a modern syntax and configuration for our project.

Today, we will talk about Android counterpart. Which will involve the “official” Android IDE from Google: Android Studio.

Language: Java, and still 1.6

Do not like iOS, Android sticks with old man Java version 1.6 due to licensing and details implementation of Android VM. Although new version of Android support for Java 1.7, but while we want backward compability, so we need to be happy without any modern features, like diamond operator (although it is supported by AS), string switch, auto resource management, etc. or lambda expression and new streaming API in Java 8.

There are not too much thing to talk about Java. It is too familiar with all of us and you as well. Of course manipulating Android resource files involve some basic knowledge about XMLs, but it is so easy with everybody.

IDE: Android Studio and Gradle

Android Studio, which is based in IntellJ IDEA, no doubt that it is a very powerful IDE. When switching from Eclipse, we do not quite like the shortcut key, or the concept about Project and Module of IDEA.

But now we all dropped Eclipse once and forever. With the release of 1.3 version, Android Studio now has enough critical features to develop a shiny Android application. Gradle now also perform quicker and more stable than early day.


Project Structure

We have a very basic project directory structure:


This should be familiar to you:

  • app: main module, which contains all source code of our Android app - build: output directory, which has been already ignored in Git
  • libs: third-party libraries, which in format of .jar
  • src: including java source and resources
  • poloPicker/viewPagerIndicator: third-party libraries which not included using Gradle by using directly source code
  • cert: a special directory which we use to store our debug/release keystore. Unified debug keystore as well help us to maintain single APK between different developer machines, we also store hash key in a text file so anyone can see and view it if needed, for Facebook configuration or Google Maps and so on. Our build.gradle has a line of configuration to point to these keystores while building.
  • Note that we also use techniques as described here to have Gradle and project configuration to be accessed globally without manually set it inside every single gradle build file.

Useful Libraries and Tools

We use a lot of libraries to reduce development time, as well as some tools for crash tracking and easier debugging.

  • Retrofit: A type-safe REST client for Android and Java, provide consistency for us when dealing with web-server and returned model object.
  • OkHttp: an HTTP client that’s efficient by default with HTTP/2 and SPDY, connection pooling and much more, integrated nicely with Retrofit
  • ButterKnife: Annotate fields with @Bind and a view ID for ButterKnife to find and automatically cast the corresponding view in your layout. Reduce a lot of findViewById call in our layouts.
  • EventBus: a publish/subscribe event bus optimized for Android. Help us to avoid any complex problem with Android intents or broadcast receives, split out data thread and UI thread.
  • Picasso: image loading library, with simple and effecient API and support for plugins.
  • Crashlytics (now Fabric): crash tracking service, free-to-use and nice dashboard as well as more features from Fabric coming soon.

Now it is quite enough for us with Beauty Me. We hope that through this case study, you should have an overview of starting a mobile-first project, and how its components is integrated. We also want to hear from you with any comment and review about our workflow and structure. It should be very good for us each time we write and realize that we should improve something to achieve better result. See you soon in next case study.