Note that some details of the lifecycle have changed, as described in the
docs:
http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle
Specifically, if you target SDK 11 or later, then onSaveInstanceState()
will be called before onStop() (not onPause()), and the
Regarding the networking on Android, last year on Google IO there was
a session about developing REST clients on Android (http://
www.google.com/events/io/2010/sessions/developing-RESTful-android-apps.html).
In the first pattern described there is a Service Helper component
that acts as a thin
Hi,
In the same reference just prior to that quoted is a similar example
of eager initialisation also.
Just pointing out that it can be done without explicit locks in some
circumstances as well, but synchronized blocks or methods is probably
more commonly/historically used when there is not much
On Tue, Jun 7, 2011 at 9:05 PM, gjs garyjamessi...@gmail.com wrote:
I saw an interesting variation in
http://www.deelin.com/downloads/books/java_concurrency_in_practice.pdf
on Page 213 -
:: snip ::
The book is well worth reading btw.
It's even better when you buy it, rather than download a
Hi,
Agreed, that is why I said the 'book'.
Regards
On Jun 8, 9:07 pm, Mark Murphy mmur...@commonsware.com wrote:
On Tue, Jun 7, 2011 at 9:05 PM, gjs garyjamessi...@gmail.com wrote:
I saw an interesting variation
inhttp://www.deelin.com/downloads/books/java_concurrency_in_practice.pdf
on
What you quoted is quintessential initialization on-demand holder. And its
supposed to be more like _eager_ init, not lazy init.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to
H-m-m-m. I see I was using my local copy instead of the online URLs
when coming up with the URLS for the online docs. But I am sure the
reader can figure out how to transform the one into the other.
On Jun 6, 3:27 pm, Indicator Veritatis mej1...@yahoo.com wrote:
You are right. It is not well
Hi,
I saw an interesting variation in
http://www.deelin.com/downloads/books/java_concurrency_in_practice.pdf
on Page 213 -
Listing 16.6. Lazy Initialization Holder Class Idiom.
@ThreadSafe
public class ResourceFactory {
private static class ResourceHolder {
public static Resource
Better pattern The Portland pattern Repository classifies double
locking as an anti-pattern, not a pattern. The Wikipedia page on it
(http://en.wikipedia.org/wiki/Double-checked_locking) gives a pretty
good sense of why, though when they talk of pertinent java bugs, they
are, of course, referring
You are right. It is not well documented. The information a developer
needs is scattered in various different places in the documentation,
such as
file:///home/mejohnsn/android-sdk-linux_x86-1.6_r1/docs/guide/topics/fundamentals.html#lcycles,
public class MySingleton {
*private* static mySingleton = null;
public static *synchronized* getMySingleton() {
if (mySingleton == null) {
mySingleton = new MySingleton();
}
return mySingleton;
}
To be absurdly pedantic, this is indeed thread-safe but overwhelmingly so.
Yep, you're correct.
However, if your 'getMySingleton()' method is called only occasionally (i.e.
it is not part of some performance sensitive code-path), making it
thread-safe like that is good enough. No need to squeeze out every
optimization.
Using DCL or the 'on-demand' holder work all
All I'm sayin is that you shouldn't use the claw-end of a hammer as a
screwdriver. :)
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group,
Mark, thanks so much for that. I had overlooked those pages in my
focus on the Javadoc.
It would be great if the germ of those nuggets were placed into the
Javadoc.
I think I have the tools to resolve these lifecycle issues.
tone
--
You received this message because you are subscribed to the
Its really not android specific, just best practices when dealing with
synchronized access to singleton objects.
Dianne, thanks for the example but maybe I misunderstood Mark's post about
static holders and Contexts. I thought he meant, and I was seeking an
example where the Context itself is
2011/6/4 Chris crehb...@gmail.com
Its really not android specific, just best practices when dealing with
synchronized access to singleton objects.
Dianne, thanks for the example but maybe I misunderstood Mark's post about
static holders and Contexts. I thought he meant, and I was seeking an
I feel that the lifecycle (of apps and activities) is not well
documented. I wish the Javadocs were somehow wikified so the vague
portions could be collaboratively identified and remedied. I only
feel I am able to identify places where questions arise, so having the
ability through OSP (I
This would have been better off as a new thread.
On Sat, Jun 4, 2011 at 1:20 PM, DulcetTone dulcett...@gmail.com wrote:
The Activity documentation does not clearly indicate the difference
between an activity being paused versus being stopped. Is a paused
activity one which has 1 or more
It is if you want to do anything smartly with remote content. Five seconds
or so before an ANR isn't much time to get stuff over HTTP with even a 3g
connection.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send
Regardless of ANRs, doing networking on the same thread as UI is unavoidably
going to result in a janky and crummy UI experience. Heck, even doing disk
IO will result in some amount of UI jerkiness and significant IO like
database operations should always be done on another thread.
On Sat, Jun
Mark, et al,
Thanks for all the replies. My use of the singleton pattern was correct
as was confirmed by these posts. I did find my issues - one of which
_was_ due to not handling lifecyle correctly - and now all is well.
...Jake
MM == Mark Murphy mmur...@commonsware.com writes:
MM Note
Hi Mark,
While thread-safety is on your mind, you should know that double-checked
locking doesn't always fix that problem either.
Cheers,
- C
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to
On Fri, Jun 3, 2011 at 10:38 AM, Chris crehb...@gmail.com wrote:
While thread-safety is on your mind, you should know that double-checked
locking doesn't always fix that problem either.
It did according to my sources. Got a better pattern?
--
Mark Murphy (a Commons Guy)
http://commonsware.com
Using a static helper inner-class that constructs and holds your singleton
eliminates the synchronization overhead and is safe and works across JVM
versions. This is the initialization on-demand holder pattern.
I believe they fixed DCL in Java 5 as long as you use volatile (by the way,
I
On Fri, Jun 3, 2011 at 11:33 AM, Chris crehb...@gmail.com wrote:
Using a static helper inner-class that constructs and holds your singleton
eliminates the synchronization overhead and is safe and works across JVM
versions. This is the initialization on-demand holder pattern.
But that's not
Wait a minute. Do you mean that this code below:
public class MySingleton {
*private* static mySingleton = null;
public static *synchronized* getMySingleton() {
if (mySingleton == null) {
mySingleton = new MySingleton();
}
return mySingleton;
}
does not fix this?
Read Double-Checked Locking; Clever but Broken
http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html
The pattern, while common, was broken prior to Java 5 and was fixed after
but only if mySingleton is declared volatile.
--
You received this message because you are subscribed to
If you are responding to Streets of Boston, that code is not doing double
check locking. It is doing the only null check with the lock held.
Personally I prefer to explicitly use synchronized() instead of synchronized
methods for legibility and to avoid leaking locking semantics out of a
class,
On Fri, Jun 3, 2011 at 12:24 PM, Chris crehb...@gmail.com wrote:
Read Double-Checked Locking; Clever but Broken
http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html
The pattern, while common, was broken prior to Java 5 and was fixed after
but only if mySingleton is declared
Not really, but to the thread in general.
Since this has gotten off topic of Android development, I'd like to try to
pull it back...
Mark if you're still paying attention, how would this come up within the
context of .. a Context? I'm having trouble seeing a useful example.
--
You received
Wow, you read my mind and beat me to it by 6 minutes. Good job.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
This is my preferred approach for implementing a singleton that needs a
Context:
static final Object sLock = new Object();
static MySingleton sInstance;
static MySingleton getInstance(Application app) {
synchronized (sLock) {
if (sInstance == null) {
I think this stuff would deserve an Android Dev blog enttry. While I
understand what you are saying, remembering it in 6 months time is a
different story. If there were a blog post to refer back to, it would
be a lot easier.
On Jun 4, 2:29 am, Dianne Hackborn hack...@android.com wrote:
This is
Note that this will only work single-threaded. Add the synchronized
keyword to the method and make the static data member volatile to make
it safe for multi-threaded access.
(a problem I ran into with WakefulIntentService, which is why this
issue is fresh in my mind...)
On Wed, Jun 1, 2011 at
So as long as I always call my getInstance() class I can be certain that
I will get a pointer to the already constructed object or that the
static instance variable had been reset to NULL triggering new
construction?
DH == Dianne Hackborn hack...@android.com writes:
DH If your process is
The code below will work fine for a singleton:
...
private static MyObject myObject = null;
public static MyObject getMyObject() {
if (myObject == null {
myObject = new MyObject();
}
return myObject;
}
Note that variable won't be 'reset' to null. There is nothing to reset when
your
you can store the data to database or serialize the object.
I guess you need keep some data or do something after app has been
stopped.
On 6月2日, 上午9时03分, Dianne Hackborn hack...@android.com wrote:
If your process is killed, the next time you run a fresh process must be
created and
37 matches
Mail list logo
