Reloading our Activities State after firing Intent to camera

by Mark Murphy » Thu, 03 Sep 2009 10:15:45 GMT


Sponsored Links
 > Mark, so I'm confused.  No, the activity was not destroyed, but it

If the activity is not destroyed, there is nothing that needs saving --
the activity is still in memory.

-- 
Mark Murphy (a Commons Guy)
 http://commonsware.com 
Android App Developer Books:  http://commonsware.com/books.html 



--~--~---------~--~----~------------~-------~--~----~



Other Threads

1. Tips on simplifying asynchronous/callback code?

Do you have a strategy (an app-internal architecture, a design
pattern?) that helps you structure your app's use of asynchronous/
callback operations like startActivityForResult() and bindService()?
Dealing with asynchronous events is standard for GUI code, but this
goes beyond that into code where you pretty much know the sequence of
events. And unlike, say, a desktop environment, you usually don't have
the option of blocking and unblocking a thread to hide the
asynchronous operation in the middle of some straight-line code.

With a typical startActivityForResult() for example, you have some
code for preparing the request Intent ("prepare-request"), some code
for interpreting the result Intent ("interpret-result"), and some code
for what to do next ("do-next"). And the do-next chunk typically
involves yet another asynchronous/callback operation.

In my first attempt at coding a use of startActivityForResult(), I had
onActivityResult() call methods in the parent Activity. I couldn't
follow my own code -- the flow of control from prepare-request to
interpret-result to do-next was just not apparent in the code! In
another callback situation, I used an anonymous inner class for my
TextToSpeech.OnInitListener, but found it similarly hard to see the
flow of control implicit in my code.

I've experimented with trying to encapsulate prepare-request and
interpret-result for a particular sub-Activity in a single class, and
passing in do-next chunks using the Command pattern, but it's
debatable whether that was any improvement.

Can you point me at better approaches for structuring this async/
callback code?

Mark

-- 

2. Featured Apps on the market never change!!!

Okay so this is something of a rant but it's worthy of discussion.

Everytime I browse the market the same ten or so featured apps appear
all the time. Over the past 4-5 months I have been using the market I
have only seen a handful of new apps make it into the featured apps on
the "welcome screen" of the market app.

In fact I can be almost certain if I were to open the market app now I
would see "{*filter*}! World Attack", "Mystique. Chapter 1" and "Layar"
forced upon me for the millionth time.

Can we not have some new "featured" apps for once and stop promoting
the same apps relentlessly?

</rant over>

--

3. BroadcastReceiver and getSharedPreferences problem

4. What is the maximum number of threads allowed per application?

5. Same servicein multiple APKs, only want "best one" to launch

6. streaming issue with mediaplayer on android 2.0

7. Two selectable items in each list Item in listView.