LMMPAA Structural DesignAn Android app should have a modular design that follows the MVC principles. The current implementation of LMMPAA is rather messy in its structural design, which makes understanding, maintaining, and improving the code unduly difficult. We should restructure the app into three modules: data, UI, and utilities. DataThere are three types of data classes: models, singleton data holders, and ESRI data classes. Models represent basic LMMP data that is independent of frontend applications. In other words, model classes should be the same regardless of whether the application is Android, iOS, or web, and regardless of whether we use ESRI or some other library. Generally speaking, model classes should simply be the Java representation (i.e. POJO) of the JSON/XML data returned by the LMMP web services. Classes such as Config, Bookmark, Layer, and so on should be model classes. Some data is shared by multiple activities (e.g. config), and the recommended way to do that is to use singleton data holders (see Chapter 9.1 of the Big Nerd Ranch Guide and Android documentation). ESRI data classes are basically wrappers of the model classes so the data can be fed to ESRI classes like MapView. ESRI data classes, e.g. WMSServiceLayer, typically inherits from some ESRI classes. UIUI classes include activities, fragments, views, as well as the adapters used by some views. UtilitiesUtility classes handle various functions such as web service access, JSON/XML parsing, caching, and so on. Each function should be properly separated from others. Problems and FixesThe main problem of current implementation is that everything is mixed together: shared data is stored in UI classes, data models hold references to parsers, parsers perform network access, and so on. We need to restructure the code to:
Please use CSNS Android App code at https://github.com/cysun/csns-aa.git as examples. |