Odtnhj

I have a model class which has below properties.

@interface CountryModel : NSObject
@property (nonatomic) NSInteger id;
@property (nonatomic, strong) NSString *country;
@property (nonatomic, strong) NSString *dialCode;
@property (nonatomic) BOOL isInEurope;
@end

I'm getting the below data from web service.

 "id": 123,
 "country_name": "India",
 "dialCode": "+91"

Then I'm binding values to the array, Now my question is how memory management will work for the model class? Because there are few has a strong reference. Can anyone explain me.

Simple answer: automatically (provided you haven't disable ARC)

Slightly longer answer (provided you haven't disabled ARC):

When you assign values to the properties country and dialCode of an instance of CountryModel then that instance will have strong references to the referenced NSString values.

If you assign a new value to either of these properties then the previous strong reference will be dropped and replaced by a strong reference to the new value.

When the instance of CountryModel is no longer strongly reference by anything then the strong references it contains will be dropped.

When a strong reference is dropped if there are no other strong references to the reference object then that object becomes reclaimable and the memory it occupies returned to the available memory pool.

Note: if an NSString reference refers to a literal string then the literal string itself is immortal and will never be reclaimed. If you are trying to gian an understanding of when memory is released by monitoring memory usage, tracking dealloc calls, etc. do not use literal strings as your test objects – it is best to use a user-defined type.

But I've disabled ARC... Then memory will get reclaimed when you manually instruct it to be. If you're getting leaks turning on ARC is your best choice, if you cannot then you've some debugging to do!

HTH

Addendum after comment

Trying to follow reference counts and expecting them to match with actual executing code doesn't work well as there are often references you do not know about in compiled code. For this reason you will see many writers discouraging tracking reference counts.

Instead think in terms of strong references making an ownership stake in an object, and as long as there is an owner the object survives.

This might seem to be essentially the same thing, but there is a subtle difference in how the two are viewed: the reference count belongs to the object; while the strong reference attribute, which asserts an ownership stake, is part of the belongs to the referencing variable.

In your comment example a has an ownership stake in the CountryModel object it references - the only ownership stake you have so far created to that object. The CountryModel object has ownership stakes in the objects that country and dialcode reference, but may not be the only such stakeholders – in that fragment we've no idea what other reference variables assert an ownership stake in the objects those two variables reference.

Later when you create temparray the object reference stored in a is copied into the array and temparray claims and ownership stake in the referenced CountryModel object – while a continues to assert its own ownership stake as well. So now you have two variables you have created asserting an ownership stake in the CountryModel object.

A similar explanation applies to b & c.

When there is no ownership stake claimed by any variable/property over an object then that object can be destroyed. As part of that destruction any variables/properties that are part of that object are destroyed and any ownership stakes they asserted over references stored in them are withdrawn.

If that process results in more objects having no more ownership stakes asserted over them then those objects too can be destroyed; the process continuing to destroy unwanted objects until the only remaining objects are those where some variable/property asserts an ownership stake over them.

HTH more than it confuses!