[Android Audit] Booking Android app decompiled and reviewed [ Nov 11, 2014 ]

Some notes on how to improve Booking for Android, experience and performance:

1. There are some keys in manifest.xml and Settings.java. Constructing keys at runtime from pieces or use bit manipulation like XOR with some string to hide the actual key should be safer:

• Maps API key: you don’t want to make it easy for others to use your quota of daily responses, if I remember correctly some APIs like places had limits.

2. AndroidManifest.xml: To avoid menu button of shame and other fragmentation related issues consider using android:targetSdkVersion=”21" in uses-sdk tag.

3. Code obfuscation can decrease app size by 1–2 MB (dex file), plus the benefit of hiding your code. I was able to decompile Booking dex and review most of the codebase, checksrc_tree.pdf.

4. Repeated issues in some layout files:

• It is better to use 4dp and its multiples (4, 8, 16, 32, …) to avoid half pixels on different densities. For example 4dp is exactly 4px on mdpi, 3px on ldpi, 6px on hdpi and 8px on xhdpi but 5dp is 3.75px on ldpi and 7.5px on hdpi.
• Hardcoded test strings (for dates and addresses for example): It is better not to do so in case it was not replaced during runtime with the correct values for whatever reason. You can define specific test strings file to be used during Gradle debug builds and an empty one for release builds.
• Make use of ____start, ____end and layout_direction layout attributes instead of duplicating most layouts for Arabic and Hebrew layouts like margin_start will translate tomargin_left on LTR devices and margin_right on RTL devices. It will only work work on 4.2+ so a mix will be needed still.

5. btn_book_now.xml: It is better to use Button widget directly with custom style, less drawing overhead.

6. Support AppIndexApi: https://developer.android.com/reference/com/google/android/gms/appindexing/AppIndexApi.html to drive/increase user engagements through Google.

7. Use SmartLock for Passwords: Can be used to automatically login users to the Android app if they already have a saved credentials in Chrome and vice-versa,https://developers.google.com/identity/smartlock-passwords/android/

8. BaseActivity.java: It is a bit heavy to have all Activities extend from it. There is no obvious reason to call checkHistoryManagerDatabase for example in each Activity onCreate. Maybe BookingApplication is a better place to load history.

9. MessageCenterItemBaseAdapter.java: Performance wise, it is better to have a finalLayoutInflater class field. It is unnecessary to call LayoutInflater.from(context) multiple times in getView method. It is not a big deal though because it will most probably be called like 5–7 times based on screen height.

10. Serializer.java: It is unnecessary to implement JsonSerializer (use generics) because all its methods are static. T is a type defined by a instance and there are no instances here.

11. UserProfile.java: Better practice to use Patterns.EMAIL_ADDRESS instead of private static final String EMAIL_REG_EXP = “…

12. SearchEditText.java: It would be more maintainable to use SearchView (with a menu item) and other platform related search components. SearchEditText is also used in couple layouts like user_credentials_form.xml not as search which is awfully misleading.

13. SpannableStringBuilder.java: paramSpannableStringBuilder.append(paramString1).append(“ “).append(paramString2); can be replaced withTextUtils.concat(paramSpannableStringBuilder, paramString1, “ “, paramString2);no difference in functionality, just improves code readability.

14. avoid_progress_dialogs.png: Because it forces user to stare at the screen with no interaction.

15. side-drawer.png: It is overwhelming and can have fewer items, items like “Lists” (require sign-in) and “Recent searches” (already visible in home screen) can be removed.

16. User interaction with side-drawers is not high so they are a bit tricky,http://thenextweb.com/dd/2014/04/08/ux-designers-side-drawer-navigation-costing-half-user-engagement/

17. wrong_overflow_menu_style.png: It is dark yet overall design feels like a Holo Light Theme.

18. inconsistent_icons_style.png: Inconsistent icons style, official Android icons could have been sufficient here.

19. Following http://source.android.com/source/code-style.html will improve code readability and maintainability. Some abstract classes for example currently in the codebase starts with Base and some do not, same for interfaces(starts with I), etc…

20. com.booking.common.data: It is an interesting package

21. Adapt modern look and feel, Material Design, I did some simple skinning to some screens and in case there is a need to change something major A/B testing can be used to validate it.