Recently, during the development of Car Maintenance we started to feel the pain of how much you want to run on any device and pondered about the cost. Having experience with mobile development we understand the concept of thin client, data terminal of most applications but in the same manner, currently, the power of the devices is incredible. The devil advocate made us create a list of why you want to balance the mobile app from thin to thick client (or not).
PRO arguments (of having a THICK client)
- database support and almost ORM libraries : if you need local processing the data has to be stored in database and you need support in terms of libraries and modernity of the databases available in mobile apps
- versatility of the language in order to implement complex logic requirements: as Java/Objective C/C# are the main languages used in native development this is a non-issue
- modern GUI support: without it we shouldn’t have seen the explosion of applications and the commoditization in price and features
- large enough screens: the 5″ to 10″ screens make the applications visually appealing and
- software support for different screens at the API level: are the differentiators were app publishers can write once for all segments (phones, tablets, phablets)
- device memory: you can store GB of data on a single phone
- new devices are 4 to 8 CPU cores (and GPU cores galore): welcome to game power
PRO arguments (of having a THIN client)
- there is no really multithreading on any mobile phone
- you don’t have the same versatility at the database level as the one available in any server (MySQL, MS SQL, PostgreSQL); running long processing data intensive tasks is not that easy done and requires a step-down and a lot of more work
- the only back-up for data is cloud (or external storage) and it comes with customized APIs
- the maturity of the GUI sophistication is at least two levels down from what you can have on a desktop solution (MVC/MVVM)
- you spend a lot of time to play nicely with the architecture of the device (rotating screens, life cycle for activities – Android, fragment integration – Android)
- the mobile data analysis comes with delay and cost of pulling it on a centralized repository (collecting it on a server)
- you have to deal with skimpy communication, store and forward mechanisms and other problems which were solved and standardized on PCs; in mobile you almost reinvent the wheel
- the size of the application does matter
- the size of the DRAM memory does matter
We were confronted with real dilemmas like:
- for reports (which are much simpler to run on servers) should you write Java code (locally) or prefer to go a round trip to server ?
- how much to present on screen and how much to load on demand
- how do you split the business logic (or whether is compelling to do it ) between server and device
- is the server controlling the application or the device
Another posting will present a real example of one of the issues summarized here (business logic on device or server).