5

It would be nice if StackOverflow had a section where we could post tutorials like mine so that I can answer literally hundreds of questions that have been asked here with a single blow. See... every day I read questions about how to pass complex objects between activities, how to save state so that your app can resume after orientation change, how to update listviews when the data changes, etc, etc.

Here is the second part of a tutorial series I posted on my blog... I hope that you actually read it... because I haven't seen any examples like it anywhere... and it has changed how I think about developing for Android across the board. The question is... is there a downside or negative affect of developing like this?

Beyond Smart Lists – How Observable Singletons change the game.

Please read through both of these tutorials carefully... I will answer any questions about it here that I can... I really want to know what you think about this and if it might solve issues for you.

NOTE TO MODERATORS: there are no advertisements of any kind on my blog.. so don't just close this because you think I am spamming somehow... I am not going to duplicate my post here. And... really I want to know if there is a flaw in this approach.

androidworkz
  • 2,902
  • 1
  • 19
  • 19
  • 1
    I think it got flagged because your subject reads, "How many of you..." which sounds subjective. Probably pass the smell test better if your subect read more like, "Is it accepted practice to use singletons to save state or share data between Activities?" – Kirk Woll Aug 14 '10 at 13:07
  • Thanks... question changed. Thumbs Up! – androidworkz Aug 14 '10 at 13:09
  • Your "SmartList" has a public constructor, so it's not really a Singleton. Is that a mistake? – DJClayworth Aug 17 '10 at 20:39
  • If your tutorial is answering hundreds of questions that are actually being asked, it would make sense to identify which questions they are and post your tutorial as an answer. – DJClayworth Aug 17 '10 at 20:41
  • I'm reluctant to provide an 'answer' without fully understanding your code, but I'll provide some feedback in comments. Your examples are very badly documented - i.e. hardly documented at all. This makes them unsuitable as tutorials. – DJClayworth Aug 17 '10 at 21:16
  • How are you distinguishing between Observers? If you have two pairs of communicators - A observing B and C observing D - how are you ensuring that C doesn't respond to changes in B? – DJClayworth Aug 17 '10 at 21:17
  • I am not using it like that... so it isn't an issue... and as far as documentation... I don't think it's necessary because the code is about as basic as you can get... if somone can't understand what the code is doing they should go buy a book... and yes the public scope of the constructor is a mistake... I made the example in about 15 minutes. – androidworkz Aug 18 '10 at 03:20
  • So am I right in understanding that your pattern can only be used when there is a single pair of classes in the system which require to communicate, and isn't extendible to the case where more than one pair of classes require to communicate? – DJClayworth Aug 19 '10 at 16:08

1 Answers1

3

Have you read about Android's Application class?

Community
  • 1
  • 1
Macarse
  • 91,829
  • 44
  • 175
  • 230
  • Yes, I have actually. There is a great tutorial about how to use it at http://www.heikkitoivonen.net/blog/2010/05/13/bacon-rank-android-app-details/ but it's not really the same approach... is it as flexible? In addition, the way these Observable objects work is that they post updates to any consuming Activity anytime their properties change... This does, however, bring up an important issue I hadn't considered. What happens if an Observer is no longer active... I am not sure if the Observable will throw an exception or not if it tries to update an Observer that doesn't exist. – androidworkz Aug 14 '10 at 13:41
  • Ok... I just ran a test and it appears that attempts to update null observers don't cause any side effetcs but it probably makes sense to call observable.deleteObserver(this) in the onDestroy() and onPause() and restore the object and Observer in onResume() or onRestoreInstanceState() – androidworkz Aug 14 '10 at 13:58
  • It is fundamental to the Observer patter that the Observer remove itself from everything it is observing when it is no longer required. In garbage-collected environments the Observer still exists as long as there is a reference to it in the Observables. Your observers should remove themselves from all their Observables when they become inactive. – DJClayworth Aug 17 '10 at 20:45
  • yep... I have actually been doing that because I did see that it was leaking memory when I didn't. – androidworkz Aug 18 '10 at 03:18