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.xml
there 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?
It's common and ok to use. Especially intended when you want to reuse code/classes, but use different layouts.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With