Protect your code

A short tip to finish the day. Do you know that when you publish your Android Application it's so easy to download and decompile it?. So everyone can use your code or even modify it to break your copy protection or any thing else.

So it is very recommended to compress and obfuscate your code. It is very easy, simply add the following line in your /default.properties file:

proguard.config=proguard.cfg

And if you use the Eclipse option Export Signed Application Package create by hand the /proguard directory.

The only precaution is to add the following line in proguard.cfg for every class you don't want to be obfuscate:

-keep public class 

Why don't obfuscate? Very easy, if the class must be accessed dynamically in runtime you cannot obfuscate it, otherwise you'll get an Classnofound error.

I hope this trick will be useful for you.

Good practices for an Android beginner

When I begin to learn some new programming language or framework, I used to search for the good and bad practices I should take into account. In this old post (http://www.codingforandroid.com/2010/12/help-for-developers.html) I recommended you the Google Application Android Dev Helper 2010. In this app, the first entry in Android section is a little guide for beginners, with good an bad practices for Android developers. Here you have a little summary of the good practices:

About beauty:

• Developers are not designers
• Use Android UI Design Patterns: Click here for more info about them
• Create assets optimized for all screen resolutions
• Support resolution independence
• Use tools to optimize your implementation as layoutopt and hierachyviewer

About generosity:

• Use intents to leverage others people's apps
• Define intent filters to share your functionality

About ubiquity:

• Create widgets
• Surface search results into the Quick Search Box
• Live folders
• Live wallpapers
• Expose Intent Receivers to share your functionality
• Fire notifications

About utility & entertaiment

• Create an app that solves a problem
• Present information in the most useful way possible
• Create games that are ground breaking and compelling

About Epicness

• Don't be satisfied with good
• Create unique solutions
• Invent new paradigms
• Leverage the hardware

I hope this is of your interest.

Bad practices coding for Android

In the last post I talked about the good practices to follow by an android beginner. Now I'm going to summarize the bad practices collected from Android Dev Helper 2010. This are common mistakes we must avoid always when coding for Android. Google talks of them as "The five deadly sins":

About Sloth:

To avoid sloth we should be fast and responsive. The clues to be fast are the next:

• Avoid creating objects (minimize it)
• Use native methods
• Virtual is better than interface
• Static is better than virtual
• Avoid internal getters an setters
• Declare constants final
• Avoid float an enums
• Use package scope with inner classes

The clues for responsiveness are:

• Avoid modal Dialogues and Activities, informing always the user with the progress and rendering and filling the data as it arrives
• Respond to the user input within 5 seconds and Broadcast Receiver must complete in 10 seconds
• Users perceive a lag longer than 100 to 200ms
• Use Threads and AsyncTask within Services

About Gluttony:

We must use system resources responsabily:

• Don't over use WakeLocks
• Don't update Widgets too frequently
• Don't update your location unnecessarily
• Don't use Services to try to override users or the system

• Do share data to minimize duplication
• Do use Receivers and Alarms not Services and Threads
• Do let users manage updates
• Do minimize resource contention

For using Wakelocks correctly:

• Do you really need to use one?
• Use the minimum level possible
• Release as soon as you can
• Specify a timeout
• Don't use them in Activities

About Hostility:

Avoid fight with your users. User experience should be your top priority and you should respect user expectations for navigating your app, avoiding hijack the native experience and respecting the user preferences:

• The back button should always navigate back through previously seen screens
• Always support trackball navigation
• Understand your navigation flow when entry point is a notification or a widget
• Navigating between application elements should be easy and intuitive
• Don't hide the status bar
• Use native icons consistently
• Put menu options behind the menu button
• Use only enabled location-based services
• Ask permission before transmitting location data
• Only transfer data in the background if user enabled

About Arrogance:

• Avoid fight the system. Take it as it is.
• Don't use undocumented APIs
• Make your app behave consistently with the system
• Respect the application lifecycle model

About Discrimination:

Since there are many devices and many SO versions, you should design and code for everyone.

• Don't make assumptions about screen size or resolution
• Never hard-code string values in code (or XML)
• Use Relative Layouts and device independent pixels
• Optimize assets for different screen resolutions
• Use reflection to determine what APIs are available
• Store values as Resources (colors, dimensions, arrays, images, layouts)