Strong vs Weak. Nonatomic vs Atomic

September 30, 2014 Leave a comment


a string reference – own the object, system will not destroy this item as long as you have this one.


A strong reference (which you will use in most cases) means that you want to "own" the object you are referencing with this property/variable. The compiler will take care that any object that you assign to this property will not be destroyed as long as you (or any other object) points to it with a strong reference. Only once you set the property to nil will the object get destroyed (unless one or more other objects also hold a strong reference to it).

a weak reference – don’t have the control of object lifetime. Referencing weakly.

In contrast, with a weak reference you signify that you don’t want to have control over the object’s lifetime. The object you are referencing weakly only lives on because at least one other object holds a strong reference to it. Once that is no longer the case, the object gets destroyed and your weak property will automatically get set to nil. The most frequent use cases of weak references in iOS are:

    delegate properties, which are often referenced weakly to avoid retain cycles, and

    subviews/controls of a view controller’s main view because those views are already strongly held by the main view.


atomic – thread safe? lock before accessing it.

nonatomic – thread not safe but fast?

atomic vs. nonatomic refers to the thread safety of the getter and setter methods that the compiler synthesizes for the property. atomic (the default) tells the compiler to make the accessor methods thread-safe (by adding a lock before an ivar is accessed) and nonatomic does the opposite. The advantage of nonatomic is slightly higher performance. On iOS, Apple uses nonatomic for almost all their properties so the general advice is for you to do the same.

Categories: Uncategorized

Finalize VS Dispose

May 21, 2014 Leave a comment

Quoted from

Finalize is the backstop method, called by the garbage collector when it reclaims an object. Dispose is the "deterministic cleanup" method, called by applications to release valuable native resources (window handles, database connections, etc.) when they are no longer needed, rather than leaving them held indefinitely until the GC gets round to the object.

As the user of an object, you always use Dispose. Finalize is for the GC.

As the implementer of a class, if you hold managed resources that ought to be disposed, you implement Dispose. If you hold native resources, you implement both Dispose and Finalize, and both call a common method that releases the native resources. These idioms are typically combined through a private Dispose(bool disposing) method, which Dispose calls with true, and Finalize calls with false. This method always frees native resources, then checks the disposing parameter, and if it is true it disposes managed resources and calls GC.SuppressFinalize.


  • Finalizers should always be protected, not public or private so that the method cannot be called from the application’s code directly and at the same time, it can make a call to the base.Finalize method
  • Finalizers should release unmanaged resources only.
  • The framework does not guarantee that a finalizer will execute at all on any given instance.
  • Never allocate memory in finalizers or call virtual methods from finalizers.
  • Avoid synchronization and raising unhandled exceptions in the finalizers.
  • The execution order of finalizers is non-deterministic—in other words, you can’t rely on another object still being available within your finalizer.
  • Do not define finalizers on value types.
  • Don’t create empty destructors. In other words, you should never explicitly define a destructor unless your class needs to clean up unmanaged resources and if you do define one, it should do some work. If, later, you no longer need to clean up unmanaged resources in the destructor, remove it altogether.


  • Implement IDisposable on every type that has a finalizer
  • Ensure that an object is made unusable after making a call to the Dispose method. In other words, avoid using an object after the Dispose method has been called on it.
  • Call Dispose on all IDisposable types once you are done with them
  • Allow Dispose to be called multiple times without raising errors.
  • Suppress later calls to the finalizer from within the Dispose method using the GC.SuppressFinalize method
  • Avoid creating disposable value types
  • Avoid throwing exceptions from within Dispose methods

Dispose/Finalized Pattern

  • Microsoft recommends that you implement both Dispose and Finalize when working with unmanaged resources. The Finalize implementation would run and the resources would still be released when the object is garbage collected even if a developer neglected to call the Dispose method explicitly.
  • Cleanup the unmanaged resources in the Finalize method as well as Dispose method. Additionally call the Dispose method for any .NET objects that you have as components inside that class(having unmanaged resources as their member) from the Dispose method.
Categories: .NET, C#

One thing to know..

May 19, 2014 Leave a comment

Never ever call or raise event in event handler.

Categories: C#

IIS 7.0. Using its machine name in WSDL instead of using domain name.

November 26, 2012 Leave a comment

In WSDL IIS 7.0 uses its machine name in URL if the value has not been given. Well it looks like a bug for an entry level programmer or admin of Windows Server.

Two ways to fix this.

1. Bind the website with a proper domain in IIS. This is working for HTTP. If the WCF service is only for HTTP, IIS will smoothly give WSDL with given domain .


2. For HTTPS, modifying the applicationHost.config is needed.
It is located in c:\Windows\System32\inetsrv\config .
We must modify protocol=”https” bindingInformation to “*” .

* this information is only for IIS7.0 above and for IIS6.0 there are some vbs to do that.

IIS 6.0 information is found in below..

Categories: .NET, WCF Tags:

Install New services on new server (IIS7.5) Default App Pool Identity

October 2, 2012 Leave a comment

Probably the app pool set with default appPoolIdentity. And the identity does not have any privilege to access local resources of server.

It could be a problem and may be cannot find why it is working.

Because the program has not permission to access local resource, an access denied exception or security exception would be occurred.

Remember!! Don’t forget!.

1. IIS –> Application Pools


2. Right click app pools –> Advanced settings


3. Change Identity  to Administrator or newIdentity which has Admin privilege.



Then, the program works fine!

휀다 넥 교환 DIY

July 23, 2012 Leave a comment


모두가 잘 아시는 휀다 USA standard 모델입니다. 어느날 넥을 교체하고 싶어 집니다. 점보 프렛에 집착하는 저에게는 미디엄 점보는 눈엣가시 입니다. 그렇다고 리프렛을 하고 싶지는 않았습니다. 원래 있던 넥 자체를 다치고 싶지 않고 싶기도 하고, 넥에는 처음부터 달고 나온 프렛이 가장 좋다는게 제 기타 인생 지론 입니다. 그렇다면.. 넥을 통째로 교환 해야죠.


이베이를 검색해 봅니다. 역시 펜더는 그 대체품이 넘쳐 납니다. 그중 점보프렛이 박혀 있는 마이티 마이트 넥으로 결정을 봤습니다. 가격 또한 착합니다. 제가 고른 녀석은 mm2928 입니다.


역시 펜더 사운드에 소스는 그 데칼에 있지요. 사운드의 격을 위해선 데칼이 반드시! 있어야 합니다. 이리저리 알아 보다가, 61년 스트랫 데칼로 결정을 봤습니다. 팔고 있는 사이트 설명에 거기에 나온 사진보다 훨씬 더 정교하게 만들어졌다고 하네요. 속는셈치고 샀는데 막상 물건을 받아보니, 퀄리티 죽이네요.


photo 2 (1)

튜닝 머신은 펜더 정품으로 결정 했습니다. Locking으로 할까.. 하다가 알아보니 비싸네요. 비싼거 싫어요. 그냥 스탠다드 헤드머신으로 할랍니다. 이베이에서 24불 합니다. 받아보니 made in Taiwan 이네요. 원래 대만에서 만드나요?? 대만에서 만드는지는 처음 알았습니다.


리테이너도 정품으로 마련했습니다. ^^ 5불이네요.


넥이 배송 오자마자 확인 해봅니다. 헤드머신 딱~ 들어맞네요. 드릴 작업후 바로 장착 해 봅니다.


자. 데칼 작업 시작 입니다. 데칼을 붙이는 것보다, 데칼을 잘 오리는게 더 중요합니다. 나름 정교하게 한다 했는데 약간 자른 자국에 거칠게 되었네요. 가위질이 정교해야 합니다.

Photo Jul 17, 2 31 51 PM

데칼을 물에 대략 30초 정도 불리고 바로 붙여야 합니다. 우물쭈물 하다간 돈 날라가기 쉽상이네요. 데칼이 머무를 곳에 물을 충분히 발라주고 데칼을 띄운후 조심스레 움직여서 고정 합니다.  할땐 잘 한것 같더만 작업후 보니 약간 옆으로 밀렸네요. 줸장..

Photo Jul 17, 2 40 59 PM

데칼이 마른후, 반드시 피니쉬 작업을 해줘야 합니다. 마른 데칼은 쉽게 벗겨집니다. 락커 피뉘시 할까 하다가, 마트 돌아다니다 보니 투명 폴리우레탄 스프레이가 있네요. 무슨 빈티지도 아니고, 언능 마르고 빨리 되는 녀석이 최고 지요. 작업은 한시간에 한번씩 뿌리고 말리고를 반복해 거의 하루종일 했습니다. 데칼 파는곳에 작업을 어떻게 해라 라고 나와 있지만 참조만 했고, 그냥 제 맘대로 했습니다. 원래는 아주 두껍게 했어야 했는데, 적당히 얇게 해도 문제는 없네요.

Photo Jul 18, 11 35 15 AM

넥을 붙여 봅니다. 아..젠장 포켓의 높이가 원래 넥보다 더 높습니다. 완전히 같지는 않네요. 게다가 넓이도 약간 아주 약간 좁습니다. 일단 붙여 봤습니다. 뭐 브릿지 스터드 높여 주니 문제는 없네요. 좀 속은 기분은 듭니다. mighty mite 부품.. 펜더 공식 replacement 이라고 하더만.. 전화해 볼껄. 약간 씁슬 합니다.

photo 3

photo 5

완성 입니다. 멀리서 보니 Eric Clapton Blackie 같네요.

Photo Jul 19, 7 01 03 PMPhoto Jul 23, 1 29 24 PM

피치가 원래것 보다 더 잘 맞습니다. 신기하네요. 데드스팟 없고, 버징 없고, 연주감 좋네요. 아쉬운 점도 없지 않지만 대만족 입니다.


아~ 사운드.
넥을 바꿔서 당연히 사운드의 차이가 있습니다. 큰 차이는 없지만, 원래 넥 보다는 소리가 미세하게 가벼워 졌다고 해야 맞을 것 같습니다.  스탠다드 휀다 사운드가 거기서 거기죠 뭐.


읽어 주셔서 감사합니다.

Categories: Guitar

WCF Extensibility–Using Message Inspectors

July 18, 2012 Leave a comment

Message inspectors are powerful to inspect inside of envelope of SOAP message. Two sides are available, client side and service side. I think that the biggest value is to inspect client side. Service side is easy to consider what is wrong actually. But client level has a different story.

Three steps are needed.

  1. Create a XXXInspector class implements IClientMessageInspector (or IDispatchMessageInspector for service side) interface.
  2. Create a XXXBehavior class implements IEndpointBehavior. Fill up ApplyClientBehavior method with adding inspector to clientRuntime.
  3. Create a XXXExtensionElement extends BehaviorExtensionElement, which is an abstract class
    And there are two ways for registering those classes.

Using .config file. – need to add custom behavior and behaviorExtensions.

In codes – my personal choice. I prefer not to tamper config file usually.


And all soap messages will be captured or modified. Smile

Categories: WCF