7

Since, I am fairly new to large scale app development in Android and Java, I thought I would ask for advice.

My team is faced with developing a prototype of a fairly complex medical software. Although it is only a prototype, I think it might be a good opportunity to learn a new platform and get into some good habits.

Our design requirements are fairly simple: a set of common files: themes, styles, objects, static methods for database etc. and then a set of smaller "apps" like: digital tests, games etc. Each one is fairly unique.

Our initial thought is to create a set of smaller applications that will be launched from "the main screen". Each application would be a separate project in Eclipse and then we would modify the build path to include the "common files". This way: each developer can work on their own projects without bothering others.

The problems that I find with this approach:

  1. Deploying the application (having a bunch of applications instead of one big one)
  2. Testing the application
  3. Use of strings to launch another application i.e. worrying whether the application has been installed
  4. Silly human errors e.g. modifying common files and forgetting to commit changes

Another solution would be to create one big application/project with each developer working on a separate package which would represent each app. However, this introduces common resources (e.g. unique string names) etc.

What's your advice about the best way to tackle this problem? Which approach is better in the long run? Are there any other approaches that are more sensible?

Lindsay Morsillo
  • 223
  • 1
  • 7
Dawid O
  • 171
  • 6
  • 2
    Well, my vote is for the single application, unless the apps are really distinct and completely independent. Who wants to install multiple apps? – Robert Harvey Sep 02 '14 at 22:36
  • @RobertHarvey rather multiple things that work together, each with a simple, easy to use, user interface than a single monstrosity where you have to click through a dozen screens and menus to get anything done... – jwenting Sep 03 '14 at 06:58
  • @jwenting: I don't dispute that, but are you really going to install a dozen apps just to get anything done? – Robert Harvey Sep 03 '14 at 15:15
  • @RobertHarvey as a corporate entity, those'd be pushed to all devices as part of setting them up from a central repository, no human interaction. – jwenting Sep 04 '14 at 06:38
  • Is it a requirement that a user be able to -not- have some of the applications installed? That is, are they supposed to be given the option to choose what they want installed to their device? If they should always have everything then make it one application. You can always break the projects up and just include them in the "main screen" app, which is the one that actually gets compiled and deployed as the .apk file. – Deco Sep 05 '14 at 02:24

1 Answers1

3

If the apps are distinct in terms of data, and purpose, I think modularizing them - making a number of smaller, separate pieces is better. If they do not share data, and if they do not have strong coupling in terms of how the user uses them, I would strive to keep them separate and small.

It all depends on the coupling between the fairly unique apps. If each is isolated and not dependent on lots of other things, it will be easier to test at a higher level. It will be easier to isolate bugs. Easier to upgrade.

You can use package manager functionality (e.g. queryIntentActivities) to find and help launch the other activities to get around problems of launching other apps.

The problems of forgetting to commit changes and other problems of that nature aren't coding or system design issues, those are practices and process problems.

Lindsay Morsillo
  • 223
  • 1
  • 7