Monday, 6 April 2015

Android - Some words about the architecture

Here are some adverts that I have to build the architecture for Android:

1. Never use the Android class AsyncTask. You will lost the number of threads executing each time. Instead, use StaticThreadPool and your own implementation of threads in Java. This will improve the performance of the app. Actually I am using StaticThreadPool of 5 threads.

2. Never use an activity as Controller. The reason is in the activity is usually linked with the views. The views will not be destroyed until the activity is destroyed. So, if an activity lives as long as the app it self, it is retaining more resources than the app needs.

3. I have a class called Session which is a singleton. It is used as the general controller. It is the abstract layer that the Activities have to communicate with Backend, the database, etc.

4. There are two main Design patterns for asynchronous task that could be used: Observers and Callbacks. The First one is the one that should be used for the communication between the activities and the Controller. The Callback is the one that should be used for the communication between layers inside the Controller. This is because:

- The async tasks takes time. If the activity uses callback, it could happens that when the callback comes back, the activity has been already destroyed. If that callback is related with any manipulation of the views, it will fails or even crash the app. The use of Observer allow the activity to unregister itself when it has been paused/stopped/destroyed. So, it is saver using Observer.

- The problem with the observer is the class could lose the consistent of the actual state because several methods could expect the same result. Then for the Update method of the observer, when a result comes, it must check which method has done the request. This does not happens with the callbacks, since each callback should be used for only one method.

5. Never abuse the fragments. It is good if you need to implement the view for both Mobile and Tablets, but when there are too much fragments for one activity, it is hard to control the stack of views. Use Activities where it is possible.

6. Avoid the use of Static methods. They are only useful for Utility classes.

7. Don't abuse the use of Singleton. An activity shouldn't be never a singleton.

8. (Personal taste). Use a base Activity where all the activities extends. This will allow the activities have less code and easier to modify.

9. Have a base style for the textView, editText, buttons and so far. The have specific styles for the textView, editText and buttons in each activity. This will maintain the consistency of the app and allow the coder to have a slightly different style per activity without losing the control of the styles. 

10. Have a class Constant is ok. If there this class has a lot of values (more than 500 lines of code), then it is better to have each one of the constants allocated in each one of the classes.

11. Be careful with the loaders. It seems an alternative for AsyncTask that what happens in reality is you lose the control of what's happening after call it in the corresponding activity or fragment. Avoid to use it if possible.

No comments:

Post a Comment