Даже на андроиде это может быть воспринято как введение пользователя в заблуждение. Например, недавний инцидент с Твитером, который на iOS спрашивал у пользователя, можно ли ориентируясь на данные в его адресной книге, найти его друзей в твитере, а заодно пересылал и хранил у себя на сервере копии всех контактов.

То есть «читать контакты» и «переслать на сервер, хранить и обрабатывать контакты» семантически все-таки несколько разные вещи.

А если она ничего не отправляет, а просто тихонько ддосит рутрекер?

Да, мне уже подробно объяснили знающие люди.

Ладно, примем как данность, что разработчикам просто захотелось сделать комбайн.

Это, конечно, очень круто, но у меня возникает один вопрос — зачем?

Я совершенно согласен. Но речь идет именно о том, что сегодня хорошо, а завтра — уже не очень.

Я просто напомню, что кошмар верстальщика под названием IE6 появился именно так.

W3C внезапно расписалась в собственной беспомощности.

Вообще, пример C++11 (или как там его) показывает, что все эти стандартизации мало того, что идут медленно и печально, так к тому же и на выходе получается не то, что надо людям, а то, что решили сделать в комитете.

Окей, есть возможности — но причин по-прежнему нет.

Никто не жалуется.

Да, в iOS 5 слегка поломали слой совместимости, и многие чужие приложения просто перестали работать. Например, нежно любимая мной Stanza. Насчет родных сказать не могу, я мало чем пользуюсь.

Я полагаю, что это может быть связано с тем, что краш программы в iOS — это настолько незаметное событие, что пользователь чаще всего не понимает, что вообще произошло. Ну и нет культуры написания баг-репортов из-за других характеристик социума.

В случае, например, если у меня крашится твитер — он просто сворачивается и айфон показывает главный экран. Я запускаю твитер — и он работает. Такое я лично у себя наблюдал, наверное, раз пять.

Другие приложения тоже иногда себя так ведут.

В результате, у разработчиков нет причин и возможностей править «плавающие» баги, которые крайне негативно влияют на статистику.

Как обстоят дела в андроиде — не знаю.

Это не Рихтер рекомендует, а МСДН. Рихтер писал, почему это плохо.

В данном случае плохо тем, что если а == b, то хеш-код у всех таких объектов будет 0.

Рекоменуется теперь использовать какой-то такой алгоритм (на память не помню, каждый раз гуглю его заново):

int A = простое число;
int B = другое просто число;
int hash = A;
unchecked
{
hash = hash * B + field;
}

Стекло вроде все-таки не жидкость, а твердое тело с аморфной кристаллической решеткой и при комнатной температуре никуда не течет.

Я не думаю, что это подходящее решение. Фактически — стрельба из пушки по воробьям.

Ну, в таком случае рекомендую почитать про COM export. Для самообразования.

Честно говоря, не вижу ничего удобного в декомпиляции и правке ассемблерного кода. При автоматической сборке на билд-сервере вы проклянете это решение.

COMExport не подходит?