I’m working on developing a medical records system using OpenMRS as a backend for Android. OpenMRS is dependent on some seriously heavyweight libraries, including Hibernate and Spring.
“Dexing” the entire OpenMRS application generates a file that’s too big even for the Android classes.dex file format (this size limit is already well-documented). To get around this, I’m currently working at creating multiple dex files from the dependencies and loading them during runtime using Android’s dex classloader.
Because of the way the mobile version of the server will be used in practice, the actual processing demands will be very low despite the huge dependencies. I’m not trying to run an enterprise server on my phone here.
Before I spend weeks more of my time trying to engineer this, I just wanted to ask the developer community: is this strategy just a pipe dream? If I load up all these libraries, will the entire binary get loaded into RAM and just break the system? Is there a good way to optimize such an application? Is there some obvious problem or solution I’m missing here?
The short answer is: Don’t.
The long answer is that most devices still only allocate a relatively small amount (between 40-128 megs of RAM) of memory to each heap. You really REALLY need to think about architecting the app so the bulk of the logic and thus the libraries and heavyweight code still reside on a server and the mobile app is just reading lightweight data (JSON?) from the server to display. Devices should really only utilize native items such as location data and provide an interface to the user that is consistent with the rest of the Android universe. Beyond that, you should be looking for ways to keep as much logic out of the native app as possible. If for no other reason than to keep it more secure. Reverse engineering Android applications is trivial and the more you keep on the server side, the more secure you will be.