CODEWITHSUNDEEP
javaandroidandroid-fragmentsandroid-activity
earizon
earizon

Reputation: 2238

Multi-activity really needed on Android?

I'm used to HTML development. Now I'm starting to program my first Android apps. In the tutorials I have read it looks like Android development favors using a new activity for each different form.

Nothing-less I think it's quite possible to use a single activity and use the setVisibility(View.VISIBLE|View.INVISIBLE) to show / hide GUI forms elements (This is much more similar to what I'm used with HTML-AJAX).

Is there something wrong with this way of development in Android?

Using a single activity(process) also allow to use singletons to share state and data between GUI components, while the multi-activity requires a "slightly" complex communication system using extra data to communicate the selected id, ...

I wonder what are the disadvantages of the single Activity "pattern" and why no tutorial/manual on the Internet use this technique to develop Android apps.

Do fragments have any advantage over showing/hiding views when I have no intention/interest to reuse the component?

Upvotes: 1

Views: 105

Answers (3)

Kushal
Kushal

Reputation: 8478

Approach : Single Activity :

  • This approach will show/hide UI elements based on user interaction with app. Showing a UI Element draws View hierarchy starting from that element. This is called Layout Pass. This layout passes are expensive operation when performance is calculated. This is not advisable way to implement.

Approach : Single Activity, Multiple Fragment :

  • This approach will also have Single Activity but multiple Fragments associated with this activity. Each fragment defines new UI screen based on application requirement. More details available : Android Developer Guide : Fragments This is much advisable way to implement your requirement

Upvotes: 2

hqt
hqt

Reputation: 30276

Do you want those code happen:

elementXScreenA.setVisibility(false);
elementYScreenA.setVisibility(false);
elementZScreenA.setVisibility(false);

elementXScreenB.setVisibility(true);
elementYScreenB.setVisibility(true);
elementZScreenB.setVisibility(true);

And then, maybe after that:

elementXScreenB.setVisibility(false);
elementYScreenB.setVisibility(false);
elementZScreenB.setVisibility(false);

elementXScreenC.setVisibility(true);
elementYScreenC.setVisibility(true);
elementZScreenC.setVisibility(true);

No. I don't want to do that !!!

That just base on your ways for funny. There are many many disadvantages to do that, and I don't think there are any advantages in this approach. I can list some. Any comments will add to this list:

  1. Design UI. How can you code multi layout on one xml layout file? Android Studio doesn't support this. You will see elements overlap elements
  2. Performance. Load all your application UI is not an intelligent way. You lost memory, lost CPU. Although you set invisible, your memory still store those information, and when transition between elements, invisible elements still count into.
  3. Maintainable. I'm working with a medium project, and still headache every day with bigger and bigger fragment and activity. (in case that each layout for each activity/fragment). How does everything become when you make all your layouts into one activity?
  4. Collaboration. All layouts in one file. All your application in one file. How can you can collaborate between members? Code conflict, wrong edit ... Noooo. Stop that :)

No. Stop that. You just make element invisible when that element need this. For example, floating button when user scroll down list, error message textbox when no error need to show, ...

Upvotes: 0

Christopher Mäuer
Christopher Mäuer

Reputation: 98

I think there is nothing wrong, but depending on how complex your app will be, the source code can easily become very confusing!

Upvotes: 1

Related Questions