Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

In Android should each screen be its own Activity or layout?

Ok I am designing an app which has a very simple layout of 62 Content Screens, accessed via 27 Menu Screens. In total this is 89 activities.

At the moment I have each Content Screen to be an Activity that just calls an XML layout (some text, buttons and image) and adds some onClick functionality.

Each Menu Screen is a ListActivity and pressing each item in the list opens that item's Activity (be it another Menu Screen or a Content Screen).

At the moment I am testing it with 3 Menu Screens and a Content Screen. It is fine scrolling through them all, however I am concerned that when I finish the app it will have too many activities and make the app slow and slugish. In an average use of the app I imagine the user would use no more than 10 activities but I am not sure if Android would be anticipating creating the other unused Activities or what.

So another way to implement this would be to have just a few Activities (maybe 1 for a MainMenu, 1 for a subMenu and 1 for a ContentScreen) that just work out which layout to display. However I feel this would mean that each Activity has a hell of a lot more work to do and also I lose the functionality of pressing the Back button taking the user back up through the menu hierarchy (and coding a replacement Back button onto each Screen would involve a massive Case for the onClick involving every single possible layout, all 89 of them!).

What would be the best way to go about this app?

Any help is very much appreciated

like image 313
Stu Avatar asked Jun 22 '11 16:06

Stu


1 Answers

Unless layouts and behaviours differ significantly between menu activities and content activities, I'd go with "just a few activities approach".

Back button won't break, Android keeps track of your backlog.

Do you really need 89 different layouts? If it's mostly content what's different between them, store content in a database or file or in /res/, reuse layouts and fill content areas of layout at runtime.


Updates:

Wouldn't it be easiest to have 1 activity per content page that in onCreate() fills in the layout with the appropriate content?

Depends on how different your onCreate() code is going to be. If your onCreate() is going to be a giant switch with 62 wildly different case clauses, then it's probably better to go with separate small activities, not a huge one. If you can generalize the onCreate() code, and keep it below, say, 100 lines and 10 branch statements, that'd be way to go.

To give an example, some time ago I was building a simple app that has a collection of exam questions, and presents them randomly to user. Each question has question text, illustration and 2-4 answers choices. There were around 500 different questions. Here's the code that loads a question from database and updates the layout. Notice that it handles variable number of answers, and possibility of some questions not having illustration.

public void loadQuestion(int id) {
    // Columns in questions table:
    // CREATE TABLE questions (
    //         id integer,
    //         q text,
    //         a1 text,
    //         a2 text,
    //         a3 text,
    //         a4 text,
    //         a5 text,
    //         correct integer,
    //         img blob
    //     );

    Cursor c = mDatabase.rawQuery("SELECT * FROM questions where id=" + id, null);
    c.moveToFirst();

    TextView text = (TextView) findViewById(R.id.text);
    text.setText(c.getString(1));

    RadioGroup g = (RadioGroup) findViewById(R.id.answers);
    g.clearCheck();

    // Load answers!
    int correct = c.getInt(7);
    int[] buttons = new int[] {R.id.a1, R.id.a2, R.id.a3, R.id.a4, R.id.a5};
    for (int i=0; i < 5; i++) {
        String answerText = c.getString(i + 2);
        RadioButton rb = (RadioButton) findViewById(buttons[i]);
        if (answerText != null && answerText.length() > 0) {
            rb.setText(answerText);
            rb.setTag(i + 1 == correct ? "correct" : null);
            rb.setVisibility(RadioButton.VISIBLE);
        } else {
            rb.setVisibility(RadioButton.GONE);
        }
    }

    byte[] encoded = c.getBlob(8);
    ImageView iv = (ImageView) findViewById(R.id.image);
    if (encoded != null && encoded.length > 0) {
        iv.setVisibility(ImageView.VISIBLE);
        iv.setImageBitmap(bytesToBitmap(encoded));
    } else {
        iv.setVisibility(ImageView.GONE);
    }
}

What do you mean by: Back button won't break, Android keeps track of your backlog?

As the user moves from activity to activity, across applications, the Android system keeps a linear navigation history of activities the user has visited. This is the activity stack, also known as the back stack. In general, when a user starts a new activity, it is added to the activity stack, so that pressing BACK displays the previous activity on the stack.

(from Activity and Task Design Guidelines)

like image 163
Pēteris Caune Avatar answered Oct 29 '22 11:10

Pēteris Caune