0

I am working on a project, which at that stage will have to be customized for different customers. Application consists of some business logic and 15 different activities for the UI. Lets assume that activity A starts B, and B starts activity C. A knows about B, B knows about C. I want to be able to swap activity B (use different layout, a bit different logic to handle user interaction), but leave A and C intact. What is the best approach to achieve that? I will have more and more different activities (serving similar purpose) for different customers, so the solution needs to handle many different configurations.

I was planning on splitting customized activities to different libraries and using DI container (RoboGuice 2.0) to inject them, depending on configuration, but it looks like i still need to put all the activities in manifest.xaml, which requires double work (editing manifest + configuring DI container).

user1079952
  • 45
  • 5

2 Answers2

1

A knows about B, B knows about C.

That does not sound very wise in this case.

I want to be able to swap activity B (use different layout, a bit different logic to handle user interaction), but leave A and C intact.

Then put A, C, and all other common code in an Android library project. Put B and other customer-specific code in a customer-specific project that depends upon the library. Have some means for A (in the library) to determine how best to launch B (for the customer). For example, you could have all customer-specific projects advertise B with the same <intent-filter> (with a nice app-specific and otherwise obscure action string), and A can simply use an Intent that will match that filter for startActivity(). A then knows about B in a generic sense ("here's the B action") without knowing the B implementation, which would be customer-specific.

I was planning on splitting customized activities to different libraries and using DI container (RoboGuice 2.0) to inject them

That sounds like swatting a fly with a Buick, but perhaps you have a long history with DI.

but it looks like i still need to put all the activities in manifest.xaml, which requires double work (editing manifest + configuring DI container)

Drop the DI container, then.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • I will try to split that code into libraries then. I considered using DI because i didnt't think of intent filters in 1st place. – user1079952 Jul 26 '12 at 11:38
0

Perhaps, instead of doing anything in your code, you could put your project under version control and, for some of your files, you can then have different branches for different customers.

Alexander Kulyakhtin
  • 47,782
  • 38
  • 107
  • 158
  • I already tried branches. The thing is that a branch = merging changes (bug fixes) which i don't want to do. If i end up having 4 branches, then it is a lot of work to integrate changes to all 4, then test all 4 etc. What i want to achive is to have a different UI for different customer (not just the colors, but the whole layout), but the data and the core logic stays the same – user1079952 Jul 25 '12 at 16:53
  • @user1079952 If you really succeed in encapsulating all of your logic/data in classes which are separated from your Activities then merging won't be a big problem as those business classes won't need branches. It looks like there should be no merging at all in this ideal case. – Alexander Kulyakhtin Jul 25 '12 at 17:22