Question

Say I have two Activities in an Android application, EditPerson and EditEmployee.

It would seem natural to have the EditPerson Activity be a base class for the EditEmployee Activity and define methods that marshal data to and from the Views defined in the layout. The EditPerson Activity’s implementation would push (for example) the “Name” field to and from an EditText element. The EditEmployee versions would call the base class version, and then marshal its own specialized fields (say a tax id, etc.).

To facilitate the shared code, both activities would have to have a layout resource that defines one or more pairs of EditText elements that share the same id. i.e. in layout\edit_person.xml there would be:

<EditText android:id="@+id/name_editor" />

And then in layout\edit_employee.xmlthere would be something like:

<EditText android:id="@+id/name_editor" />
<EditText android:id="@+id/tax_id_editor" />
<!-- etc. -->

Since the “Employee” is a “Person”, and there are fields in common (marshaled via inheritance), it would seem as if the id assigned (“name_editor” in the above example) only has to be unique within the scope of an activity (or layout?).

From my testing, this appears to work, but I am paranoid that there would be a unintentional side effect to this approach and use of ambiguous layout element ids. Can anyone confirm that this is a safe practice and/or point out how it will eventually blow up my application? Has anyone ever done similar things?

Answer 1

It’s common and ok to use. Especially intended when you want to reuse code/classes, but use different layouts.