При разработке софта под iPhone, столкнулся с проблемой непонимания механизма распределения памяти. Являясь java-разработчиком, привыкшим к чудесам Garbage Collector'а, тема памяти в Objective C поначалу доставляла мне массу неприятностей. Спустя некоторое время, написав свое первое приложение, я подумал, что полностью разобрался в этой непростой теме... и это было моей ошибкой. Все таки, сначала надо хорошо читать мануалы и желательно до конца :)
Назвал я данную тему непростой не из-за сложности механизмов управления памятью - они то как раз более-менее понятные и простые, а, скорее, из-за того, что не разобравшись до конца, как правильно "освободить" объект из памяти, можно получить массу сложноотлавливаемых ошибок типа EXC_BAD_ACCESS, причем необязательно именно в том месте, где была допущена ошибка распределения памяти.
Если вы хоть раз занимались разработкой программного обеспечения под iPhone, то наверняка встречались с ошибкой EXC_BAD_ACCESS. Отловить ее достаточно непросто, т.к. встроенный дебагер не покажет вам нужный стектрейс и тем более не подскажет, как все исправить.
Что же такое EXC_BAD_ACCESS? Мне удобнее сравнивать эту ошибку с NullPointerException в Java, т.к. возникает она в ситуации, когда вы отправляете "сообщение" объекту, который уже был выгружен из памяти (released). Например, попробуйте создать объект с помощью alloc и затем два раза подряд его "отпустить" с помощью release.
Так как же быть, если у нас достаточно большой проект с массой кода и объектов? Как проще и быстрее отловить данную ошибку? На помощь придет директива NSZombiEnabled, установленная в переменных окружения проекта. Все, что она сделает - это заставит Objective C runtime оставлять объект-пустышку за каждым выгруженным реальным объектом и в следующий раз, когда вы попытаетесь обратиться к своему выгруженному объекту, вызов пойдет именно к пустышке, которая остановит выполнение кода и выведет короткое и ясное сообщение в дебагер о том, какой объект был вызван и что за сообщение ему было отправлено. Стектрейс при этом также не будет испорчен, и сможет дать дополнительную информацию о месте баги.
Простой пример для тех, кто ищет простой и быстрый путь отформатировать дату при разработке под iPhone. В моем примере будем форматировать дату по стандарту RFC2822.
Данный подход достаточно прост и эффективен, но у него есть один минус - куча строк, которые придется писать каждый раз, когда надо сделать преобразование. Чтобы этого избежать можно сделать так:
Представим ситуацию, что у нас многопотоковое приложение, написанное на Java. Есть некий класс, выполняющий какое-либо конкретное действие с данными, например, отправку их по почте, а сами данные подготавливаются в другом месте кода в другом потоке. Перед отправкой данных нам необходимо как-то связаться с потоком, подготавливающим данные, дабы поймать момент, когда они будут готовы.
Пример 1. Простой, но неправильный пример
Регулярные выражения в Java? А почему бы и нет, как говорится. Время от времени неизбежно появляется необходимость их использовать, чтобы разбить строку на подстроки или, например, отформатировать данные. Сделать это можно несколькими разными способами.
Способ первый, он же самый простой, для несложных манипуляций - использовать встроенные методы класса String для работы с регулярными выражениями.
Пример 1.1. Разбивание строки на массив строк.
Каждый java-разработчик рано или поздно сталкивается с необходимостью переопределения метода equals, а соответственно и hashCode(). Кто-то пишет их сам, кто-то использует прибамбасы среды разработки. Например, я частенько использовал автоматическую генерацию в среде IDE Intellij IDEA (ALT + Insert / equals() and hashCode()), пока не нашел "красивое" решение, реализованное в библиотеке org.apache.commons - HashCodeBuilder() и EqualsBuilder().
Конечно, кто-то скажет, зачем использовать какие-то дополнительные библиотеки и классы, когда все можно самому написать. Ну, что сказать, на вкус и цвет...
В самом начале своего нелегкого пути по изучению Hibernate и фреймворка Spring для Java столкнулся с проблемой возникновения некого LazyInitException, когда пытался получить некий объект, ссылку на инстанс которого содержал другой, полученный от хибернейта.
Как всегда, горел очередной проект и читать документации особо было некогда, поэтому, пробежавшись быстро по поисковикам, уловил основной смысл данного поведения - при описания меппинга одного объекта по-умолчанию все его связи с другими объектами воспринимаются Hibernate как "ленивые". Иными словами, при наполнении данными объекта Group, который, к примеру, содержит в себе List users и связан с таблицей USER как One-To-Many, Hibernate не пойдет по этой связи наполнять данными список. Сделает он это лишь тогда, когда мы обратимся к этому списку. Здесь то и кроется корень проблемы - в моем приложении обращение к списку шло в тот момент, когда хибернейт сессия работы с базой, в которой я получил объект Group была уже закрыта. Отсюда и LazyInitException.
Во время разработки программного обеспечения под iPhone столкнулся со следующей проблемой. Стандартная среда разработки позволяет запускать приложение на эмуляторе телефона, либо на самом аппарате (дабы была возможность протестировать все на реальной платформе). Так вот, если выбрать второй вариант, среда разработки попытается поставить созданное приложение на телефон и тут то и начинаются проблемы. Сначала Xcode дал критическую ошибку на тему того, что не задан какой-то сертификат. Выяснилось, что чтобы получить данный сертификат необходимо отстегнуть Apple минимум 100 баксов!
1. Форматирование чисел в денежных форматах:
2. Форматирование по шаблону
Простой пример, как можно отформатировать дату на jsp странице с помощью fmt taglib.
Последние комментарии
5 дней 21 час назад
6 дней 16 часов назад
1 неделя 1 час назад
1 неделя 18 часов назад
1 неделя 18 часов назад
1 неделя 18 часов назад
1 неделя 18 часов назад
1 неделя 18 часов назад
1 неделя 18 часов назад
2 недели 1 день назад