#nsobject

[antonio081014]

How to compare objects of your custom NSObject subclass?

Comparison of any two NSObject objects or the objects of NSObject subclass could be very useful, when you are sorting, being unique in collection, or other cases. For example, you need to have your NSObject subclass objects added to or removed from a NSMutableSet, the Set needs to well identify which object is which, so there will be no duplicates. Then, the comparison of objects will be used to help.

How can we do it? Simple.

1st, Overwrite isEqual:(id)object function.

- (BOOL)isEqual:(id)object { if ([object isKindOfClass:[DeviceSensorStruct class]]) { DeviceSensorStruct *obj1 = (DeviceSensorStruct *)object; if (self.deviceID == obj1.deviceID && self.sensorID == obj1.sensorID) { return YES; } else { return NO; } } return NO; }

2nd, Give your object a meaning ful hash value.

- (NSUInteger)hash { return (int)(self.deviceID) * sizeof(unsigned char) + (int)(self.sensorID); }

[whoistuanhai]

So sánh hai object

Việc so sánh sự bằng nhau của 2 object là vô cùng hữu ích. Tuy nhiên, nên tránh so sánh chúng bằng toán tử ==, vì như vậy là chúng ta đang so sánh 2 con trỏ chứ không phải là 2 object mà con trỏ trỏ tới. Thay vào đó, ta nên dùng hàm isEqual: được định nghĩa trong NSObject protocol. Thông thường, 2 object thuộc 2 class khác nhau thì không bằng nhau. Một vài object cung cấp các hàm đặc biệt để kiểm tra tính bằng nhau của hai object nếu chúng cùng một class. Ví dụ:

NSString *foo = @"Foo 123"; NSString *bar = [NSString stringWithFormat:@"Foo %i",123]; BOOL equalA = (foo == bar); // NO BOOL equalB = [foo isEqual:bar]; // YES BOOL equalC = [foo isEqualToString:bar]; // YES

Ở ví dụ này, ta có thể thấy được sự khác biệt giữa toán tử == và các hàm kiểm tra sự bằng nhau. NSString là một ví dụ của một class implement hàm kiểm tra tính bằng nhau của riêng mình, cụ thể là hàm isEqualToString:. Tham số truyền vào phải là một NSString, nếu không kết quả trả về là undefined. Hàm này sẽ nhanh hơn hàm isEqual: do đã biết trước kiểu của tham số.

Hai hàm quan trọng nhất trong việc kiểm tra tính bằng nhau từ NSObject protocol là:

- (BOOL)isEqual:(id)object; - (NSUInteger)hash;

Implementation mặc định của hai hàm này từ NSObject class làm việc như sau: 2 object bằng nhau khi và chỉ khi giá trị con trỏ của chúng hoàn toàn giống nhau. Bất kể 2 object nào mà được xác định là bằng nhau sử dụng hàm isEqual: đều trả về giá trị giống nhau trong hàm hash. Tuy nhiên, hai hàm cùng trả về giá trị giống nhau trong hàm hash không nhất thiết phải bằng nhau theo hàm isEqual:. Ví dụ:

#import @interface Person : NSObject @property (nonatomic, copy) NSString *firstName; @property (nonatomic, copy) NSString *lastName; @property (nonatomic, assign) NSUInteger age; @end

Hai object Person bằng nhau nếu tất cả các property đều bằng nhau. Hàm isEqual: được viết như sau:

- (BOOL)isEqual:(id)object { if (self == object) { return YES; } if ([self class] != [object class]) { return NO; } Person *otherPerson = (Person *)object; if (![_firstName isEqualToString:otherPerson.firstName]) { return NO; } if (![_lastName isEqualToString:otherPerson.lastName]) { return NO; } if (_age == otherPerson.age) { return NO; } return YES; }

Đầu tiên, kiểm tra hai con trỏ của 2 object, nếu chúng giống nhau, 2 object bằng nhau. Sau đó, kiểm tra class của hai object, nếu chúng khác nhau, hai object không thể bằng nhau. Cuối cùng, kiểm tra các property của 2 object, nếu bất cứ property nào khác nhau, 2 object không bằng nhau, nếu không, chúng bằng nhau.

Do 2 object bằng nhau phải trả về cùng một giá trị hash, nhưng 2 object có cùng một hash chưa chắc đã bằng nhau. Vì vậy, chúng ta cần phải override hàm hash nếu đã override hàm isEqual:. Một hàm hash hoàn toàn có thể viết như sau:

- (NSUInteger)hash { return 1000; }

Tuy nhiên, viết như trên có thể ảnh hưởng đến perfomance khi thêm một object vào một collection, do hash được sử dụng làm index trong hash table mà collection sử dụng. Một set implementation có thể sử dụng hash để đặt object vào trong các array khác nhau. Khi một object được thêm vào set, array tương ứng với hash của nó được liệt kê để xem có bất cứ object nào trong array bằng nhau. Nếu có, object đã có trong set. Vì vậy, nếu ta return cùng một giá trị hash cho tất cả object và thêm vào 1000000 object vào set, mỗi lần sau đó, khi ta thêm vào một object, set phải quét tất cả 1000000 object đó. Một cách viết khác của hàm hash như sau:

- (NSUInteger)hash { NSString *stringToHash = [NSString stringWithFormat:@"%@:%@:%i", _firstName,_lastName,_age]; return [stringToHash hash]; }

Viết như trên hoàn toàn hợp lệ vì khi hai object bằng nhau sẽ trả về cùng một giá trị hash. Tuy nhiên, cách này còn chậm hơn cả cách trả về cùng một giá trị hash cho tất cả object vì phải tạo ra một string. Nó có thể tạo ra vấn đề về perfomance khi thêm vào collection do hash phải được tính toán cho object được thêm vào collection. Cách cuối cùng được viết như sau:

- (NSUInteger)hash { NSUInterger firstNameHash = [_firstName hash]; NSUInterger lastNameHash = [_lastName hash]; NSUInterger ageHash = _age; return firstNameHash ^ lastNameHash ^ ageHash; }

Cách này đứng giữa sự hiệu quả và việc tạo ra ít nhất một vài khoảng hash. Vì vậy, tất nhiên, sẽ có sự xung đột giữa các hash tạo ra bằng cách này, nhưng ít nhất, nhiều giá trị trả về là có thể. Sự cân bằng giữa tần số xung đột giữa các hash và perfomance của hàm hash là điều mà bạn nên thí nghiệm và xem cái gì phù hợp với object của mình.

Các hàm isEqual: cụ thể cho một class

Ngoài NSString class, các class mà cung cấp hàm so sánh bằng nhau cụ thể là NSArray (isEqualToArray:), NSDictionary (isEqualToDictionary:). Cả hai hàm đều throw một exception nếu object truyền vào không phải array hay dictionary. Objective-C không có kiểm tra strong type tại compile time, vì vậy, ta có thể dễ dàng vô tình truyền vào một object với kiểu sai. Vì vậy, cần chắc chắn rằng kiểu truyền vào là kiểu đúng.

Bạn có thể quyết định tạo riêng một hàm kiểm tra tính bằng nhau cho một class cụ thể, nếu việc kiểm tra là thường xuyên. Lý do khác nữa là nhìn hàm đó sẽ dễ đọc hơn. Nếu như đã quyết định tạo một hàm riêng, vẫn nên override hàm isEqual. Ví dụ, class Person có thể viết như sau:

- (BOOL)isEqualToPerson:(Person*)person{ if (self == person) { return YES; } if (![_firstName isEqualToString:person.firstName]) { return NO; } if (![_lastName isEqualToString:person.lastName]) { return NO; } if (_age == person.age) { return NO; } return YES; } - (BOOL)isEqual:(id)object { if ([self class] == [object class]) { return [self isEqualToPerson:object]; }else{ return [super isEqual:object]; } }

Deep Equality vs Shallow Equality

Khi tạo một hàm kiểm tra tính bằng nhau riêng, cần quyết định xem sẽ kiểm tra toàn bộ object hay chỉ một vài trường. NSArray kiểm tra hai array có bằng nhau không bằng cách kiểm tra số lượng phần tử của array, nếu bằng nhau, kiểm tra lần lượt từng phần từ bằng cách gọi hàm isEqual:. Nếu tất cả phần từ bằng nhau, hai array bằng nhau, còn được gọi là Deep Equality. Tuy nhiên, đôi lúc, bạn chắc chắn rằng chỉ cần so sánh một số phần dữ liệu trong object là đủ xác định tính bằng nhau, nó vẫn hợp lệ nếu bạn không kiểm tra toàn bộ object.

Ví dụ, ở class Person, nếu object lấy ra từ một cơ sở dữ liệu, thường sẽ có thêm một property là identifier để sử dụng làm primary key trong cơ sở dữ liệu.

@property NSUInteger identifier;

Trong trường hợp này, bạn có thể quyết định chỉ cần kiểm tra nếu hai identifier trùng nhau thì hai object bằng nhau.

Ghi nhớ

Override hàm isEqual: và hàm hash nếu muốn kiểm tra tính bằng nhau của object

Hai object bằng nhau có cùng hash nhưng hai object có cùng hash chưa chắc đã bằng nhau

Xác định xem những gì cần thiết để kiểm tra sự bằng nhau hơn là kiểm tra toàn bộ các property

Viết một hàm hash mà có perfomance chấp nhận được

[alldonegoodbye]

Using - (id)copyWithZone:(NSZone *)zone and NSCopying

@interface MyCustomClass : NSObject - (id)copyWithZone:(NSZone *)zone { MyCustomClass *result = [[[self class] allocWithZone:zone] init]; // If your class has any properties then do result.someProperty = self.someProperty; return result; }

[ioscodesnippet]

Cancelable Scheduled Blocks in Objective-C

Sometimes you'd really want to perform a delayed action for your apps. We'll create a category on NSObject to provide a really handy usage.

The best thing with this snippet is your scheduled operations are cancelable, so you can choose to only perform your latest triggered operation (e.g. for your table view cells maybe?)

Usage:

[self performBlock:^(void) { NSLog(@"delayed operation!"); } afterDelay:2];

Handy right? You may also interest about how others doing in alternative ways. [Delayed Blocks in Objective-C](http://forrst.com/posts/Delayed_Blocks_in_Objective_C-0Fn) [Easy Delayed Messaging using NSProxy and NSInvocation](http://atastypixel.com/blog/easy-delayed-messaging-using-nsproxy-and-nsinvocation/) Updated 17 May 2012: Thanks [Jesse Armand][] ‏suggesting [this][1] great article for using the `dispatch_source` in GCD [1]:http://www.mikeash.com/pyblog/friday-qa-2010-07-02-background-timers.html [Jesse Armand]:https://twitter.com/#!/jessearmand/status/202976529800630272

[ns2ultimate]

Basic Packet Forwarding in NS2

 [ Table of Contents ] [ Previous Section ] [ Next Section ] 

Note: The content in this series is extracted from the book, Introduction to Network Simulator NS2. You may have to read chapters 4, and 5 of the book for better understanding.

What's in this post?

In this post, I will show you how packets are forwarded in NS2. This is a very fundamental and is one of the most important concept in NS2.

Preliminaries

This post relies heavily on the concept of Network Objects or NsObjects. You can read this link to for the background. 

Basic Packet Forwarding in NS2

View more presentations from Teerawat Issariyakul.

------------- Related Codes --------------

Packet reception function of class NsObject

class NsObject : public TclObject,public Handler { public: NsObject(); virtual void recv(Packet*,Handler*)=0; }

Example use of packet reception function: Classes Connector and DropTail

void Connector::drop(Packet* p){ if (drop_ != 0) drop_->recv(p); else Packet::free(p); }

void Queue::recv(Packet* p, Handler*) { double now = Scheduler::instance().clock(); enque(p); if (!blocked_) { p = deque(); if (p != 0) { blocked_ = 1; target_->recv(p, &qh_); } } }

======================================================

T. Issaraiyakul and E. Hossain, “Introduction to Network Simulator NS2”, Springer 2009. Buy it now from Amazon:

   You may also find lecture notes and other resource at the following website:http://www.ece.ubc.ca/~teerawat/NS2.htm

[disobedient-cocoa]

Memory Efficiency

This blog is sponsored by Fuel Collective, LLC. the creators of such cool apps as Permute, Pochade, Snippet and Eon.

It’s been a long time since I posted here last time and there’s many reasons to it, though the most obvious one is that I haven’t had any time. Literally – no time on my hands. As I'm unable to make sure updates to this blog would be regular, I'm (at least for now) not going to work on these lessons anymore. However, from time to time I'll drop by to say hi and to write about some technique I've learned.

This time, I'd like to talk about memory efficiency. I'm sure there’s a lot of articles out there covering this topic in general, but not that many of those try to focus on Objective-C.

Computers currently tend to have more and more memory, faster CPUs, busses have greater bandwidth, etc. Do we really need to be memory efficient anymore? The answer is yes, we do. Remember that all of the data put into the memory has to be loaded from somewhere, it has to go through the CPU, making your app less efficient in general. Also, current operating systems tend to run more and more background processes, which also take up memory. I am always wondering, when I see my MBP with 4GB RAM to have 2GB swapped out – what so important is taking up 6GB of memory?! Just think about how much text this is, that it’s more than the size of most computers' hard drives 10 years ago.

The question is what to do – how to be more memory-efficient. To answer that, we need to examine, what’s taking up most of your app’s memory. It’s usually data that you load from somewhere (cache, online data, etc.), mostly images, which can take up a lot of memory. With NSImages, always (unless it’s posing some performance issues), use the constructors that have “…ByReferencingFile:” or “…ByReferencingURL:” – don’t unnecessarily use the constructors that load the whole image into memory on init, as it may not be needed at all later on.

Next, think about what data do you really need to have in memory. It’s completely OK to store the data that you think might not be used for a while on the disk and then read it when needed. But note that all disk reads are in its core syscalls (system calls – special instructions that “ask” the kernel to do something – they require a context switch which takes about 100-200 instructions) and that the disks are always slower compared to memory. Just make sure only data that won’t be needed in the near future (say a minute+) is cached.

That’s about for the general advice, google for more if you're interested, this can be applied to any programming language and as I've said, I want to focus on ObjC. The question here is how to store the data in memory. Use custom objects? NSDictionaries? Something else?

I've created a little experiment. Create an array and fill it with 100,000 objects which contain 5 strings that are generated (I was using NSString’s stringWithFormat and was passing current date divided by some random numbers), so that all of the pointers are unique.

First, I've used NSDictionaries to store the data. The process ended up roughly on 342MB of RAM.

Then I've created my own class, which had 5 NSString* properties which were assigned the same objects as the NSDictionaries were filled with. In my results the custom objects were a little more efficient, though not by much (from which you can see NSDictionary /or more likely CFDictionary/ is quite efficient when it comes to memory).

For the last test, I went low-level. No, not assembler low, just C-low. I created a struct, which had 6 char* pointers, into which I malloc'ed just enough memory so that the string would fit with a few char padding and I've wrapped the pointer to the struct in NSValue – voila, I was at 190MB. That’s almost just half the ObjC usage, right?

So what’s the conclusion? The more low-level you go, the better. Of course, it would be hard to write everything in C, that’s why there’s object-oriented programming, right? Just keep in mind that this C struct took up (on a 64-bit computer including the actual strings) just something over 120 bytes in theory – of course, as I was malloc'ing mostly short strings under 32 bytes, so I was wasting a lot of memory (as malloc usually will mark the whole 32 bytes as used up). Again, in theory, all the 100,000 items could fit into 10MB of RAM if I really wanted (would require some manual memory management). Yeah, I know, you think I'm insane proposing you should be allocating continuous pieces of memory and then dividing them into structs, but hey, in the times a computer had 1MB of RAM, this is how it was done.

The biggest disadvantage with the last solution really isn’t working with C-strings and structs – that’s not that hard, really. The issue here is comparing items and calling methods on them – it would require you to use a custom object that’s just a wrapper for a struct pointer – generally like NSValue is – providing all the interface methods, which isn’t that hard, really.