1

I'm parsing a huge xml to display a list of titles in a listview in activity A. However the same xml also has details for a list item which needs to be shown in a different view (like list mail subjects/view mail details scenario).

On click event of this list i dont want to load a new activity with a bundle, parse the same xml and show detailed view, while i have the required data in activity A itself.

I figured out a way to hide show layouts in my XML to do this as required, but handling back button is an issue. I can probably do this by capturing back button action, but want to know whether there is a better solution for this.

Like broadcasting an intent to A (from A itself) and somehow managing to add that to the activity stack.

Excuse if there is a duplicate question, couldnt find one when i searched.

BTW, i dont want to do a solution with a database caching.

mays
  • 347
  • 1
  • 3
  • 11

4 Answers4

1

Handling back press is the easiest way to go.

Else you could also pass the information to view as Intent extra to the second activity.

Another possibility is to have a local service running in the background and in charge of loading your XML and offering access to its information in a convenient way.

You can also stuff the XML content in an Application object of your own. However I have had not so great experience with that option in some projects.

Vincent Mimoun-Prat
  • 28,208
  • 16
  • 81
  • 124
  • @ handling back press- agreed is a solution, is there a better one ? Calling a new activity means parsing the xml again for the app. I would love to avoid that. – mays Jul 21 '11 at 13:24
  • offering access to its information in a convenient way -> do you mean caching it on a static member ? any other ideas? stuff the XML content -> not a possible option for this project – mays Aug 03 '11 at 14:18
1

I would handling the back press. Just use a flag within your activity that tells you in which view you are (so back within the detailed view shows you the overview view).

Another way would be to save the values in your applicationContext. Much easier way to do it than database usage. Take a look at an answer here: How to declare global variables in Android?

But I would definitely go with handling back presses. I have a solution similar to this where I use the same listview in the layout and instead I use different adapters depending on which detailed view the user is in.

Community
  • 1
  • 1
David Olsson
  • 8,085
  • 3
  • 30
  • 38
  • I have a solution similar to this -> Mind if you share this ? BTW. I went ahead with the back button solution and a history manager implementation to do a user friendly back action implementation. Will post these details soon. Thanks for your reply – mays Aug 03 '11 at 14:21
  • Sorry, but I have updated that code and removed that. I had a boolean variable to know which view I was in. Overriding the onKeyBack I just checked the value of that variable and either quit the activity or change the adapter by just putting listview.setAdapter(firstAdapter) – David Olsson Aug 04 '11 at 09:11
1

I would use a second activity. Pass additional data (like contact list, message details, etc.) to it and display it. How you keep parsed XML in memory is up to you to decide (static member? yuck! but it works).

Now back to original Activity. Does your source XML change a lot? Maybe you can parse it and put all data into a DB so that you could retrieve necessary (and hierarchical) data quicker. This way you do not need to deal with storing lots of data in memory, re-parsing and you could perform search faster.

Audrius
  • 2,836
  • 1
  • 26
  • 35
  • Didnt want to do the second activity, also the DB approach. Settled with the layout hide/show and back button approach. thanks for your reply – mays Aug 03 '11 at 14:22
0

On click event of this list i dont want to load a new activity with a bundle, parse the same xml and show detailed view, while i have the required data in activity A itself.

Cache the parsed XML in a static data member. Your activities that need the data look at the static data member first, then kick off the parsing if and only if that cache is not there.

IOW, this is not an activity problem, but a data model problem. Do a better job with your data model, and your activities can behave naturally.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491