Comments 105
Даже не будучи разработчиком iOS-приложений, считаю очевидным, что тактика if(device == 'iPhone') (или ifdef, не важно) — это полное говно, запутывающее и утяжеляющее код.
а что вы предлагаете? У вас наверное особая тактика?
Я согласен с Ueasley
Можно написать базовый класс для отрисовки чего либо, затем сделать два наследника — один рисует для айпад, другой для айфона.
Когда приложение запускается, оно в зависимости от девайса создает экземпляр нужного класса.
Как-то так.
Можно написать базовый класс для отрисовки чего либо, затем сделать два наследника — один рисует для айпад, другой для айфона.
Когда приложение запускается, оно в зависимости от девайса создает экземпляр нужного класса.
Как-то так.
Вы предлагаете использовать паттерн Adapter, есть еще куча паттернов, которые помогают объектную модель сделать проще и отказавшись от линейной модели программирования сделать код более понятной. В статье кстати написано, кстати, что вы их сами изучите, и соответственно сами будете их использовать. Здесь уклон в другую сторону: в сторону быстродействия (НУ ОЧЕНЬ КРИТИЧНО) и минимизации кода. Представте что вы своим насследованием потяните кучу изменений классов. В Картотеке например присутствует 6-уровневое наследование виджетов, что каждую ветвь перенаследовать? Кстати паттерны учат нас избегать наследования в пользу композиции, это так — к слову.
Не смешно.
Это не обработка изображений или звука, а простое GUI приложение.
> Представте что вы своим насследованием потяните кучу изменений классов
Когда у вас ifdef-ов будет более 100 — расскажете как вам весело. Это из практики.
Это не обработка изображений или звука, а простое GUI приложение.
> Представте что вы своим насследованием потяните кучу изменений классов
Когда у вас ifdef-ов будет более 100 — расскажете как вам весело. Это из практики.
ну что вам так не нравятся ifdef, сравните количество символов ifdef и количество строк новых классов, мне кажется числа будут сопостовимы, это вам не JAVA а Objective-C. Язык на котором писалась NEXT Step, помните в 80-х как там все в 3D крутилось? Технологиие обогнавшие десятилетия. Думаете не было тогда макросов? Кстати сейчас картотеку портируют под Android и есть проблемы с памятью… нет, это конечно же не из-за того что там нет макросов
Вы когда нибудь искали ошибку, которая находится в кода макроса? :-)
практика поиска ошибок с макрасами элементарная — во первых умные IDE затеняют ветви препроцесоров, которые не будут исполнятся, во вторых есть дебагер, который пошагово проходит нужные строки.
Я просто сталкивался с С/С++ многоплатформенными библиотеками такими как OpenCV, BOOST и не боюсь макросов, и вам рекомендую не переживать, они бывают неизбежны и очень полезны.
Я просто сталкивался с С/С++ многоплатформенными библиотеками такими как OpenCV, BOOST и не боюсь макросов, и вам рекомендую не переживать, они бывают неизбежны и очень полезны.
Макросы это неизбежное зло. Но это зло! Поэтому там где это возможно их стоит избегать. Ну и конечно макросы вида #iphone, #ipad и т.д. вообще только гвозди вбивают в гроб. Какая тут кроссплатформенность? Появится еще устройство и опять все макросы перебивать? Лучше уж тогда #handset_ui #mobile_ui #desktop_ui и т.д.
обоснуйте, это может оказаться забавным :-)
Был спор по GOTO, зло ли это? Нужно ли его использовать? Кароче спор никто не выйграл, но языки программирования начали от него избавлятся. Типо чтобы народ не шубуршил и фигней не страдал с обсуждениями. :-)
Как вы думаете насчет перспектив макросов?
Был спор по GOTO, зло ли это? Нужно ли его использовать? Кароче спор никто не выйграл, но языки программирования начали от него избавлятся. Типо чтобы народ не шубуршил и фигней не страдал с обсуждениями. :-)
Как вы думаете насчет перспектив макросов?
Они были нужны на заре эволюции языков программирования. Сейчас многое изменилось, и макросы можно и нужно избегать.
Макросы выкинуты почти из всех современных языков, а если они и есть, то куда более мощные и безопасные, чем примитивный макроязык Си.
Это Java современный? а дотнет?
И где там макросы? А в дотнетовских языках, в каком-то из них был свой макроязык, но не такой убогий, как в Си.
Макросы вообще костыль в принципе
Макросы вообще костыль в принципе
в C# точно есть макросы, в Java нет, потому что это чистый ООП. У меня другое виденье макросов, мне кажется это не костыль а хадулька, благодаря которой можно быть ваше и ходить быстрее, уж последнее вы не будуту отрицать?
Кстати думаю могу привести пример кода, изрезанного макросами, которой в объектной модели даст жуткий полиморвизм, который будет очень тяжело поддерживать с учетом виртуализации Obj-C
Кстати думаю могу привести пример кода, изрезанного макросами, которой в объектной модели даст жуткий полиморвизм, который будет очень тяжело поддерживать с учетом виртуализации Obj-C
Ха, зато народ теперь другую ерунду придумал
do
{
//…
if (cond) break;
//…
}
while (false);
do
{
//…
if (cond) break;
//…
}
while (false);
Зло-зло.
Задать константы макросами — да пожалуйста, но писать большой код — оч. плохо.
Задать константы макросами — да пожалуйста, но писать большой код — оч. плохо.
Константы макросами? Ну уж увольте, а потом будут косяки при сложении двух таких констант.
static const int удобнее и лучше компилятором проверяется.
static const int удобнее и лучше компилятором проверяется.
Вы поройтесь в коде того же STL, Boost' и быстро поймете, какой это ад постоянно поддерживать гору кода с огромными кол-вом ifdef и прочих кривостей. Написать один раз и забыть — ОК, но если это Long Term Support — другое дело.
STL, Boost' это С++, это дырявый ООП в котором куда страшнее не макросы, а template.
Однако согласен частично, но это не означает что ifdef надо полностью избегать, иногда они даже упрощают логику и понимание программы. Полиморфизм на ваш взгляд чем проще? Виртуализация чем по вашему упрощает в месадж-ориентированных языках жизнь команды разработчиков?
Однако согласен частично, но это не означает что ifdef надо полностью избегать, иногда они даже упрощают логику и понимание программы. Полиморфизм на ваш взгляд чем проще? Виртуализация чем по вашему упрощает в месадж-ориентированных языках жизнь команды разработчиков?
Ориентированностью IDE и других средств разработки на ООП: легче и навигация, и рефакторинг. Плюс это банально легче поддерживать, с точки зрения расширения функциональности или кол-ва поддерживаемых платформ, как в нашем случае.
> STL, Boost' это С++, это дырявый ООП в котором куда страшнее не макросы, а template.
«Если вы такие умные, то почему строевым шагом не ходите?»
Как-то так… Грустно…
«Если вы такие умные, то почему строевым шагом не ходите?»
Как-то так… Грустно…
DaemonI — плюсанул
> ну что вам так не нравятся ifdef, сравните количество символов ifdef и количество строк новых классов
C классами порядка больше.
> Кстати сейчас картотеку портируют под Android и есть проблемы с памятью…
* Создавать объекты по мере необходимости
* Обращаться за нужной порцией данных в БД (Apple такое решение для афйоном сама советовала)
C классами порядка больше.
> Кстати сейчас картотеку портируют под Android и есть проблемы с памятью…
* Создавать объекты по мере необходимости
* Обращаться за нужной порцией данных в БД (Apple такое решение для афйоном сама советовала)
Вы же сами предложили использовать MVP и MVC. Для каждой платформы — свой V.
расскажу про свою собственную «особую» тактику.
1) замечу, что почему-то многие программисты стремятся к сокращению объемов кода/уменьшению количества файлов. На первый взгляд, стремление здравое, но оно обычно порождает вот такие вот ifdef'ы и прочая.
2) смысл моего подхода — максимально разорвать связи между стандартными компонентами и отделить логику работы программы от ее представления. Для этого я использую мааленькую библиотечку PureMVC (http://www.puremvc.org). Для нее имеется порт под Obj-C, но я предпочитаю свой собственный кастомный вариант.
3) использование данной библиотеки однозначно увеличивает количество файлов в проекте (каждому визуальному компоненту надо сделать свой медиатор и т.п.), НО, помимо остальных преимуществ, весь проект оказывается весьма приятно структурированным, что положительно сказывается на дальнейшей поддержке. Например, я могу открыть какой-то старый проект и всегда буду знать, что где находится и за что отвечает — для больших проектов во много десятоков и сотен тысяч строк это очень большой плюс.
4) В итоге, внешний вид программы получается полностью оторванным от логики ее работы, эти две сущности живут параллельно и друг от друга никак не зависят. При загрузке мы инстанцируем соответствующие платформе визуальные компоненты, и не более того.
P.S.: на первый взгляд может показаться, что этот подход мало чем отличаеся от описанного в статье, но, поверьте, это немного не так. Смысл в том, что разрыв между сущностями происходит на более высоком уровне, чем предлагает стандартный подход конкретной платформы. Поэтому, после некоторой тренировки, его можно использовать единообразно на любой платформе — например, я использую эту библиотеку для написания программ на C++, Javascript, Actionscript, Obj-C. Дополнительный бонус — облегченное портирование между платформами.
1) замечу, что почему-то многие программисты стремятся к сокращению объемов кода/уменьшению количества файлов. На первый взгляд, стремление здравое, но оно обычно порождает вот такие вот ifdef'ы и прочая.
2) смысл моего подхода — максимально разорвать связи между стандартными компонентами и отделить логику работы программы от ее представления. Для этого я использую мааленькую библиотечку PureMVC (http://www.puremvc.org). Для нее имеется порт под Obj-C, но я предпочитаю свой собственный кастомный вариант.
3) использование данной библиотеки однозначно увеличивает количество файлов в проекте (каждому визуальному компоненту надо сделать свой медиатор и т.п.), НО, помимо остальных преимуществ, весь проект оказывается весьма приятно структурированным, что положительно сказывается на дальнейшей поддержке. Например, я могу открыть какой-то старый проект и всегда буду знать, что где находится и за что отвечает — для больших проектов во много десятоков и сотен тысяч строк это очень большой плюс.
4) В итоге, внешний вид программы получается полностью оторванным от логики ее работы, эти две сущности живут параллельно и друг от друга никак не зависят. При загрузке мы инстанцируем соответствующие платформе визуальные компоненты, и не более того.
P.S.: на первый взгляд может показаться, что этот подход мало чем отличаеся от описанного в статье, но, поверьте, это немного не так. Смысл в том, что разрыв между сущностями происходит на более высоком уровне, чем предлагает стандартный подход конкретной платформы. Поэтому, после некоторой тренировки, его можно использовать единообразно на любой платформе — например, я использую эту библиотеку для написания программ на C++, Javascript, Actionscript, Obj-C. Дополнительный бонус — облегченное портирование между платформами.
Да, стремление сокращение кода есть: меньше кода — меньше ошибок.
ну про C++ понятно, а как с другими языками то?
Вот интересно на Obj-C вы под какие платформы пишите? Поделитесь опытом. Был ли опыт именно кросплатформеного написаниея и какие платформы?
Javascript, Actionscript вообще непонятно, зачем это было необходимо? Кросбраузерность что ли какая?
ну про C++ понятно, а как с другими языками то?
Вот интересно на Obj-C вы под какие платформы пишите? Поделитесь опытом. Был ли опыт именно кросплатформеного написаниея и какие платформы?
Javascript, Actionscript вообще непонятно, зачем это было необходимо? Кросбраузерность что ли какая?
тут понимаете в чем дело, очень часто стремление к «меньше кода» выливается в бурный рост этого самого кода начиная с какого-нибудь среднего этапа разработки, когда переделывать архитектуру уже поздно. Поэтому зачастую выгоднее выбрать такой подход, который дает «меньше кода» в среднесрочной перспективе, а не сиюминутно. А так, конечно, само понятие «меньше» — весьма субъективно :-)
«javascript, actionscript & etc» — это способ портировать _логику_ работы программы, т.е. то, как там данные гуляют внутри программы и к каким изменениям состояний отдельных компонентов они приводят. Как пример, один наш проект, около 150к строчек исходных текстов пережил трансформацию С++ -> Actionscript -> C++. Первое портирование было весьма трудоемким и сложным, по-сути пришлось написать программу заново. Второе портирование было сделано за пару недель времени, благодаря тому, что в обоих случаях система строилась вокруг PureMVC. В придачу код «усох» раза в два, по сравнению с первоначальной версией, хотя чего-либо лишнего в исходной программе естественно не наблюдалось и вся архитектура в целом считалась удачной… Этот же проект сейчас портируется на Javascript.
Я не рекламирую данный подход как панацею от всех бед, более того, все плюсы и минусы MVC известны давно. Но, как показывает моя практика, большинство программистов почему-то не задумываются о том, что использовать данный подход можно не только тем способом, который предлагает целевая платформа, но и полностью абстрагируясь от платформы.
ObjC — iphone/ipad, под мак, увы не делал ничего.
«javascript, actionscript & etc» — это способ портировать _логику_ работы программы, т.е. то, как там данные гуляют внутри программы и к каким изменениям состояний отдельных компонентов они приводят. Как пример, один наш проект, около 150к строчек исходных текстов пережил трансформацию С++ -> Actionscript -> C++. Первое портирование было весьма трудоемким и сложным, по-сути пришлось написать программу заново. Второе портирование было сделано за пару недель времени, благодаря тому, что в обоих случаях система строилась вокруг PureMVC. В придачу код «усох» раза в два, по сравнению с первоначальной версией, хотя чего-либо лишнего в исходной программе естественно не наблюдалось и вся архитектура в целом считалась удачной… Этот же проект сейчас портируется на Javascript.
Я не рекламирую данный подход как панацею от всех бед, более того, все плюсы и минусы MVC известны давно. Но, как показывает моя практика, большинство программистов почему-то не задумываются о том, что использовать данный подход можно не только тем способом, который предлагает целевая платформа, но и полностью абстрагируясь от платформы.
ObjC — iphone/ipad, под мак, увы не делал ничего.
я думаю информация тут изложенная очень полезна и для меня будет и пусть будет стыдно тому кто минусовал.
Я думаю, что вы чисто «академический» программист, или я не знаю, как это назвать. Я таких встречал: они шарят в матане, физике, еще чем-то, плюясь слюной сражаются за быстродействие, любят быстрые велосипеды. А еще они пишут говнокод.
для Ueasley81 или Ueasley71 комментарий возможно и был бы уместен, а вот для Ueasley91 пока что рановато делать такие далеко идущие выводы на основании нескольких комментариев незнакомого человека…
#if (TARGET_IPHONE_SIMULATOR)
MPMusicPlayerController *mpPlayer = nil; // Иначе очень сильно тупит,
// так как MPMusicPlayerController
// в симуляторе не реализован
#else
MPMusicPlayerController *mpPlayer = [MPMusicPlayerController iPodMusicPlayer];
#endifКакие ваши действия по исправлению кода?
а если через два месяца реализуют в симуляторе, то искать все места где он используется????
я бы завернул MPMusicPlayerController в прокси-класс и сделал бы реализацию этого прокси-класса для каждой платформы свою. В симуляторе она бы писала бы в лог, что типа вот дела то-то. А на айфоне бы перенаправлялись бы все вызовы оригинальному MPMusicPlayerController. При добавлении новой платформы достаточно было бы добавить новый прокси-класс для реализации функционала для новой платформы.
Но это правильный путь, а если нужно просто забить гвоздь, чтоб одна строчка кода не мешала — то Ваш метод годится.
я бы завернул MPMusicPlayerController в прокси-класс и сделал бы реализацию этого прокси-класса для каждой платформы свою. В симуляторе она бы писала бы в лог, что типа вот дела то-то. А на айфоне бы перенаправлялись бы все вызовы оригинальному MPMusicPlayerController. При добавлении новой платформы достаточно было бы добавить новый прокси-класс для реализации функционала для новой платформы.
Но это правильный путь, а если нужно просто забить гвоздь, чтоб одна строчка кода не мешала — то Ваш метод годится.
хорошее предложение, поскольку Proxy не сильно утежелит MPMusicPlayerController, я думаю. Но в местах, где быстродействие критично — определите свой макрос в проекте и пользуйтесь им. Кстати метод Krypt рекомендован Apple
В данном случае — единственная строка в инициализации приложения, реализация одной из дополнительных «фич»
А я бы написал например так (это вовсе не означает, что я критикую ваш метод, я наоборот за него):
В таком случае при добавлении поддержки в симуляторе достаточно было бы изменить MPMPC_NOT_SUPPORTED на true (и это изменение не затронуло бы других мест, где идет проверка на симулятор)
<code class="cpp"><span class="preprocessor">#if (MPMPC_NOT_SUPPORTED)</span> MPMusicPlayerController *mpPlayer = nil; <span class="comment">// Иначе очень сильно тупит, </span> <span class="comment">// так как MPMusicPlayerController </span> <span class="comment">// в симуляторе не реализован</span> <span class="preprocessor">#else</span> MPMusicPlayerController *mpPlayer = [MPMusicPlayerController iPodMusicPlayer]; <span class="preprocessor">#endif</span></code>
В таком случае при добавлении поддержки в симуляторе достаточно было бы изменить MPMPC_NOT_SUPPORTED на true (и это изменение не затронуло бы других мест, где идет проверка на симулятор)
Статья тяжеловато написана, особенно сломало мозг предложение
Смахивает на некачественный перевод.
По тому, что смог понять, ситуация, к которой приходишь с опытом разработки, описана довольно точно.
Люди часто боятся нового, и устаревший механизм прекомпиляции кода (такой как макросы) не переваривают.
Смахивает на некачественный перевод.
По тому, что смог понять, ситуация, к которой приходишь с опытом разработки, описана довольно точно.
мне тоже мозг сломала эта фраза, давайте автора попросим исправить? Мне кажется автор имел в виду тот факт, что устаревшие макросы не хотят реанимировать и давать им НОВУЮ жизнь, даже там где они становятся актуальными
Уточнить, думаю, стоит. Правда, кажется, имелось в виду то, что макросы настолько устарели, что для кого-то они являются чем-то новым, все же речь идет про механизм а не конкретные макросы.
Или у вас есть «мифический» оригинал? ;)
Или у вас есть «мифический» оригинал? ;)
Да, я участвовал в конференции где на эту тему был доклад
summer2010.etalks.ru/
Немного рекламы: материал (в том числе и видеосъемку) можно преобрести тут
www.stepinsoft.com/shop/etalks-summer-2010/
summer2010.etalks.ru/
Немного рекламы: материал (в том числе и видеосъемку) можно преобрести тут
www.stepinsoft.com/shop/etalks-summer-2010/
автор вас услышал:)
Статья человека, который первый раз столкнулся с кроссплатформенной разработкой. В данном случае нужно поддерживать одновременно две платформа — айфон и айпад (да железо одно, да ОС одна, но пратформы разные).
По поводу макросов для каждой платформы, когда платформы 2 — это еще приемлемо. Когда 3 — это терпимо. Но если больше — это уже невыносимо. Таким образом использование макросов для разделения кода приводит к заведомому забиванию гвоздя в масштабируемость и расширяемость. Я согласен что этот метод применим, если горят сроки и четко ограничего количество платформ. Но если позволяет время, лучше сделать все правильно.
Спавиться с кроссплатформенностью помогают паттерны, например фабрика и фабрика классов. Стратеги и визитер тоже часто помогают. Ну и естественно не брезговать стандартной в iOS моделью MVC. Так что рекомендую ознакоится с технологиями кросплатформенного программирования и не считать себя Колумбом в этой области.
А если Вы захотите еще настольную MAC версию сделать ??? еще одна ветка ??? или заново все писать ???
По поводу «пишите свои компоненты» могу долго и нудно спорить. Но дело ваши, грабли будут бить Вам по голове.
По поводу макросов для каждой платформы, когда платформы 2 — это еще приемлемо. Когда 3 — это терпимо. Но если больше — это уже невыносимо. Таким образом использование макросов для разделения кода приводит к заведомому забиванию гвоздя в масштабируемость и расширяемость. Я согласен что этот метод применим, если горят сроки и четко ограничего количество платформ. Но если позволяет время, лучше сделать все правильно.
Спавиться с кроссплатформенностью помогают паттерны, например фабрика и фабрика классов. Стратеги и визитер тоже часто помогают. Ну и естественно не брезговать стандартной в iOS моделью MVC. Так что рекомендую ознакоится с технологиями кросплатформенного программирования и не считать себя Колумбом в этой области.
А если Вы захотите еще настольную MAC версию сделать ??? еще одна ветка ??? или заново все писать ???
По поводу «пишите свои компоненты» могу долго и нудно спорить. Но дело ваши, грабли будут бить Вам по голове.
1. Вы все таки не согласны что макросы это правилно в данном контексте, когда критична память и процессор?
2. Паттерны в статье предлагается открыть для себя самостоятельно, это значит что в данном контексте они не используются, у вас не возникает вопроса почему?
3. «А если Вы захотите еще настольную MAC версию сделать ??? еще одна ветка ??? или заново все писать ???» Вот тут вы себе противоречите, как раз будет куча веток классов наследования, каждый композитор будет перенаследован, кроме того будет написано куча обслуживающего кода: адапторы, фабрики. Кроме того поедит производительность. Кроме того стоит учитывать тот факт что iPhone/iPad — почти идентичные платформы, следовательно код у них почти одинаков, меняется представление и чаще всего оно всего лишь расширяется для iPad. А под Mac используются совершенно другие компоненты и поведение, для него можно портировать только МОДЕЛЬ. Впринципе модель можно портировать под любую платформу.
4. Свои компоненты чаще всего неизбежны за счет ограничений стандартных. Чего тут спорить? Ну никак нельзя UISplitViewController посадить на навигатор, что вы предложите в замен?
2. Паттерны в статье предлагается открыть для себя самостоятельно, это значит что в данном контексте они не используются, у вас не возникает вопроса почему?
3. «А если Вы захотите еще настольную MAC версию сделать ??? еще одна ветка ??? или заново все писать ???» Вот тут вы себе противоречите, как раз будет куча веток классов наследования, каждый композитор будет перенаследован, кроме того будет написано куча обслуживающего кода: адапторы, фабрики. Кроме того поедит производительность. Кроме того стоит учитывать тот факт что iPhone/iPad — почти идентичные платформы, следовательно код у них почти одинаков, меняется представление и чаще всего оно всего лишь расширяется для iPad. А под Mac используются совершенно другие компоненты и поведение, для него можно портировать только МОДЕЛЬ. Впринципе модель можно портировать под любую платформу.
4. Свои компоненты чаще всего неизбежны за счет ограничений стандартных. Чего тут спорить? Ну никак нельзя UISplitViewController посадить на навигатор, что вы предложите в замен?
Вам жалко несколько килобайт памяти? Не на том вы экономите.
это вы к чему? А процессорное время мне тоже жалко. :-)
Хотите сказать, что много процессорного времени будет тратится? Да при использовании промежуточного класса в виде фабрики вместо этого спагетти с макросами почти не будет оверхеда.
я хочу сказать что там где платформы почти идентичны, код почти один, писать кучу классов для того чтобы блюсти все почести ООП не разумно, нужно пользоваться уметь не только ООП, но и макросами. goto кстати еще жив в objective-c :-)
По соотношениям Количество кода/Ошибки, Время разработки/читаемость кода, Масштабиремость / Быстрота исполнения в конкретном продукте я посчитал макросы идеальным решением
По соотношениям Количество кода/Ошибки, Время разработки/читаемость кода, Масштабиремость / Быстрота исполнения в конкретном продукте я посчитал макросы идеальным решением
Вот ничего они не почти идентичны. Вы размеры экрана смотрели, а предполагаемую модель управления приложением? Вот как раз в этом смысле айфон и айпад далеко не идентичные.
«goto кстати еще жив в objective-c „
он жив только благодаря тому, что objective-c — это в первую очередь C.
“По соотношениям Количество кода/Ошибки, Время разработки/читаемость кода, Масштабиремость / Быстрота исполнения в конкретном продукте я посчитал макросы идеальным решением»
Странно, а я именно по этим критерям считаю его самым худшим решением. Так как поддержка кода, содержащего такой подход, — это просто ад.
он жив только благодаря тому, что objective-c — это в первую очередь C.
“По соотношениям Количество кода/Ошибки, Время разработки/читаемость кода, Масштабиремость / Быстрота исполнения в конкретном продукте я посчитал макросы идеальным решением»
Странно, а я именно по этим критерям считаю его самым худшим решением. Так как поддержка кода, содержащего такой подход, — это просто ад.
да, полная поддержка С.
Вы же не писали для Картотеки код, откуда вам знать что это для нее наихудшее решение?
Вы видимо предположили из своего опыта, очевидно негативного, а я пытался донести до вас свой позитивный опыт. Это рецепт, одного из блюд, которое может быть использовано совместно с другими.
Вы же не писали для Картотеки код, откуда вам знать что это для нее наихудшее решение?
Вы видимо предположили из своего опыта, очевидно негативного, а я пытался донести до вас свой позитивный опыт. Это рецепт, одного из блюд, которое может быть использовано совместно с другими.
Ничего, пройдут годы и прийдет опыт :-)
1. Макросы неизбежны. Но исользовать их для разделения кода платформ плохое решение. Практически идеальным примером кросс-платформенного кода является ядро Linux, там есть макросы, но посмотрите как они используются.
2. Треть статьи описывает модификацию паттерна MVC. Почему бы не описать простые паттерны для написания кросс-платформенного кода, мне не понятно.
Я не говорю что нужно тут описывать паттерны, наоботор. Просто нужно упомянуть хотя-бы названия (а лучше со ссылками) те паттерны, которые будут полезны.
3.Нисколько не противоречю. Код и проект долежн быть один. Разделение платформ должно происходить за счет паттернов и архитектуры а не за счет ветвлений кода макросами. Иначе прийдется портировать кусками, как Вы и предложили, например портировать Модель. Но портировать код — это значит сделать отдельную ветку, и поддерживать теперь прийдется две модели, хоть вышли они из одной точки. Плюс появится еще один код.
Мод Мак как раз испольузется тоже Cocoa. Они немного различаются, но это один фреймворк и один код. Просто для разных целевых платформ у него различное поведение заложеное как раз паттернами, а не ветвлениями макросов.
4. Расширение стандартных компонент — это не написание собственных. Это расширение стандартных.
2. Треть статьи описывает модификацию паттерна MVC. Почему бы не описать простые паттерны для написания кросс-платформенного кода, мне не понятно.
Я не говорю что нужно тут описывать паттерны, наоботор. Просто нужно упомянуть хотя-бы названия (а лучше со ссылками) те паттерны, которые будут полезны.
3.Нисколько не противоречю. Код и проект долежн быть один. Разделение платформ должно происходить за счет паттернов и архитектуры а не за счет ветвлений кода макросами. Иначе прийдется портировать кусками, как Вы и предложили, например портировать Модель. Но портировать код — это значит сделать отдельную ветку, и поддерживать теперь прийдется две модели, хоть вышли они из одной точки. Плюс появится еще один код.
Мод Мак как раз испольузется тоже Cocoa. Они немного различаются, но это один фреймворк и один код. Просто для разных целевых платформ у него различное поведение заложеное как раз паттернами, а не ветвлениями макросов.
4. Расширение стандартных компонент — это не написание собственных. Это расширение стандартных.
2. Хорошее предложение, на самом деле в Картотеке использовались паттерны и очень активно, но в разделении кода почти не было необходимости, то есть там где код отличался координально было удобнее разделить на подклассы, а если разница всего в две строки неохото было наследовать, и фабричными методами переопределять поведение, согласитесь?
3. я бы сказал парадигма одна, контролы и суп из них отличаются. Суть в том что кода надо будет настолько больше переписывать, что я лично не вижу делать его единым. Но не об этом статья, и не будет под Mac Картотеки, уверяю вас. Статья про iOS.
4. Вы уверены что UISplitViewController можно для этого расширить? Дело в том что ограничения стоят на уровне архитектуры. Я читал много статей о нем и все писали свои варианты, ни видел я даже попыток его расширить. Многие компоненты Apple не поддаются дресировки, именно потому что написаны на месадж-ореентированном языке, как это не звучит странно
4.
3. я бы сказал парадигма одна, контролы и суп из них отличаются. Суть в том что кода надо будет настолько больше переписывать, что я лично не вижу делать его единым. Но не об этом статья, и не будет под Mac Картотеки, уверяю вас. Статья про iOS.
4. Вы уверены что UISplitViewController можно для этого расширить? Дело в том что ограничения стоят на уровне архитектуры. Я читал много статей о нем и все писали свои варианты, ни видел я даже попыток его расширить. Многие компоненты Apple не поддаются дресировки, именно потому что написаны на месадж-ореентированном языке, как это не звучит странно
4.
2. Соглашаюсь, паттерны не панацея и все хорошо в меру.
3. Статья как раз больше чем об iOS, статья о кроссплатформенности. А это тернистый путь :-)
4. С UISplitViewController знаком вскольз. Ограничение я это видел. Оно мне кажется странным и я уверен что в будущем оно исчезнет. Именно поэтому Ваш подход написания собственного аналога — это workaround (или «гвоздь» по русски), чтоб обойти это ограничение. Его нельзя считать правильным подходом. Это не значит, что так делать нельзя. Более того я практически уверен, что Ваше решение обойти проблемму самое логичное и оптимальное. НО!!! я в корне не согласен с утверждением «ПИШИТЕ СВОИ КОМПОНЕНТЫ». Я уверен что нужно писать свои компоненты только в крайнем случае имея очень везкие аргументы, а лучше и факты R&D работы.
3. Статья как раз больше чем об iOS, статья о кроссплатформенности. А это тернистый путь :-)
4. С UISplitViewController знаком вскольз. Ограничение я это видел. Оно мне кажется странным и я уверен что в будущем оно исчезнет. Именно поэтому Ваш подход написания собственного аналога — это workaround (или «гвоздь» по русски), чтоб обойти это ограничение. Его нельзя считать правильным подходом. Это не значит, что так делать нельзя. Более того я практически уверен, что Ваше решение обойти проблемму самое логичное и оптимальное. НО!!! я в корне не согласен с утверждением «ПИШИТЕ СВОИ КОМПОНЕНТЫ». Я уверен что нужно писать свои компоненты только в крайнем случае имея очень везкие аргументы, а лучше и факты R&D работы.
А зачем делать два приложения при помощи макросов, если можно сделать это при помощи обычных if-ов? Мне кажется так будет удобней всем, и автору приложения, и его пользователями.
Model-View-Presenter, кстати впервые был замечен вовсе на в .NET: en.wikipedia.org/wiki/Model-view-presenter
Model-View-Presenter, кстати впервые был замечен вовсе на в .NET: en.wikipedia.org/wiki/Model-view-presenter
разницы в написании кода практически нет, но вот в продукте конечном…
макросы позволяют на этапе копиляции убрать ненужный код в конечном приложении, ну например объявили вы массив в iPad для класса и где небудь держите миллион экземпляров этого класса, оно надо iPhone?, память нужно экономить у мобилок
Или метод вызывается в цикле миллион итераций, а в методе надо делать проверку? Насколько все замедлится?
А где был замечен впервые MVP?
макросы позволяют на этапе копиляции убрать ненужный код в конечном приложении, ну например объявили вы массив в iPad для класса и где небудь держите миллион экземпляров этого класса, оно надо iPhone?, память нужно экономить у мобилок
Или метод вызывается в цикле миллион итераций, а в методе надо делать проверку? Насколько все замедлится?
А где был замечен впервые MVP?
в википедии…
The model-view-presenter software pattern originated in the early 1990s at Taligent, a joint venture of Apple, IBM, and HP, and was the underlying programming model for application development in Taligent's C++-based CommonPoint environment.
The model-view-presenter software pattern originated in the early 1990s at Taligent, a joint venture of Apple, IBM, and HP, and was the underlying programming model for application development in Taligent's C++-based CommonPoint environment.
>макросы позволяют на этапе копиляции убрать ненужный код в конечном приложении, ну например объявили вы массив в iPad для класса и где небудь держите миллион экземпляров этого класса, оно надо iPhone?, память нужно экономить у мобилок
Это в теории. На практике, у всех девайсов на iOS достаточно много памяти, чтобы плевать на это.
Где впервые был замечен MVP, можно прочитать в статье по ссылке в разделе history.
Это в теории. На практике, у всех девайсов на iOS достаточно много памяти, чтобы плевать на это.
Где впервые был замечен MVP, можно прочитать в статье по ссылке в разделе history.
> Это в теории. На практике, у всех девайсов на iOS достаточно много памяти, чтобы плевать на это.
в сравнении с Android да, но я на практике встречал задачи для iOS, в которых памяти нехватает и постоянно происходят Memory Warnings, соответственно виджеты перезагружаются и это сказывается на быстродействии
в сравнении с Android да, но я на практике встречал задачи для iOS, в которых памяти нехватает и постоянно происходят Memory Warnings, соответственно виджеты перезагружаются и это сказывается на быстродействии
Не совсем понимаю отличия presenter от controller, или же presenter — это тот самый skinny controller?
Плохое решение. Представьте себе код с _ифами_ для проекта большего чем Hello, World
А теперь — более-менее правильное решение с макросами :-)
MyUiControlBase {}
MyUiControlForIPhone: MyUiControlBase {}
MyUiControlForIPad: MyUiControlBase {}
#ifdef _IPAD_
#define MyUiControl MyUiControlForIPad
#else
#define MyUiControl MyUiControlForIPhone
#endif
MyUiControlBase *pControl = new MyUiControl();
А теперь — более-менее правильное решение с макросами :-)
MyUiControlBase {}
MyUiControlForIPhone: MyUiControlBase {}
MyUiControlForIPad: MyUiControlBase {}
#ifdef _IPAD_
#define MyUiControl MyUiControlForIPad
#else
#define MyUiControl MyUiControlForIPhone
#endif
MyUiControlBase *pControl = new MyUiControl();
а мой MVC последние года 3 это оказывается MVP, спасибо, что открыли глаза :)
мне кажется четких граний нет, эти границы начинаешь ощущать когда у тебя неожиданно вырастает код UIViewController и сыпятся warnings со словами типо вы забыли объявленные классы связать с визуальным представлением в контроллере, при добавлении новых компонентов. А впринципе как не назови все одно — меньше связанностей — больше свободы :-)
getButtonWithTitle @«Зарегистрироваться» позабавило. Да и комментарии в коде на русском. Неужели у них нет нормальной системы интернационализации для приложений?
if ([UIDevice currentDevice].userInterfaceIdiom == UIUserInterfaceIdiomPad)
Не учите плохому :) Данный код упадет на iOS с версией меньше 3.2.
Нужно использоать макрос
UI_USER_INTERFACE_IDIOM()который проверяет или объект обрабатывает сообщение
userInterfaceIdiomКак-то так:
if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad)
мне кажется этот код просто не будет компилироваться под iOS с версией меньше 3.2, но с тем что нужно использовать макрос UI_USER_INTERFACE_IDIOM() с вам не согласятся разве что противники макросов :-) сам я не пробовал этой кухни, потому что у нас все проекты идут отдельно на iPhone и iPad приложения и я пользовался только макросами
Сейчас весь код собирается в SDK 4.x, по-этому все скомпилируется без проблем но не будет работать.
Я не смог скомпилировать приложение для устройства iOS с версией ниже 3.2 из xCode 3.X и дырявого xCode 4 тоже не смог с установленной SDK 4.0, вообще при выборе устройства было написано четко «missing». Расскажите, как вам удалось собрать код под устройство ниже 3.2
1. Надо все собирать в SDK 4, старые более не поддерживаются.
2. Как устройство выбираете iPhone 4. Потом можно в свойствах проекта / таргета задать deployment target. Там может быть меньшая версия. Еще скорее всего надо использовать weak linking для UIKit.
Тут расписано поподробнее — blog.federicomestrone.com/2010/07/18/base-sdk-deployment-target-weak-linking-and-import/
2. Как устройство выбираете iPhone 4. Потом можно в свойствах проекта / таргета задать deployment target. Там может быть меньшая версия. Еще скорее всего надо использовать weak linking для UIKit.
Тут расписано поподробнее — blog.federicomestrone.com/2010/07/18/base-sdk-deployment-target-weak-linking-and-import/
UFO just landed and posted this here
угу, препроцессинг неплох, но когда в самих макросах нет логики ).
А вообще похожесь платформ смущать не должна — либо делать приложение которое само собой масштабируется под размеры экрана, либо уж делать приложение с отдельной специально заточенной для другого устройства мордой.
А вообще похожесь платформ смущать не должна — либо делать приложение которое само собой масштабируется под размеры экрана, либо уж делать приложение с отдельной специально заточенной для другого устройства мордой.
для iPhone/iPad в описанном вами случае все куда проще. Пишется два разных ipadiphone.m и линковщику через проект указывается нужная реализация и все, никаких макросов даже не нужно.
«Макросы штука хорошая, но они плохо масштабируются.» фраза не о чем, подкрепите фактами.
«Макросы штука хорошая, но они плохо масштабируются.» фраза не о чем, подкрепите фактами.
UFO just landed and posted this here
Да, я тоже видел кстати изящные решения, в библиотеке OpenCV исключения как раз такие: автоматом указывают файл и строку происхождения, как в самых современных ООП языках. Еще говорят удачный пример хорошего использования макросов в движке халвы.
Через строку #ifdef достаточно весело, но за счет подсветок IDE в принципе уваривать можно.
Через строку #ifdef достаточно весело, но за счет подсветок IDE в принципе уваривать можно.
Простите, немного не по теме.
Можно немного об UIUtils sizedButtonFromImageNamed? Если я правильно понял, то создается красивая кнопка, которая, ко всему прочему, может еще и растягиваться. Каков принцип работы?
Можно немного об UIUtils sizedButtonFromImageNamed? Если я правильно понял, то создается красивая кнопка, которая, ко всему прочему, может еще и растягиваться. Каков принцип работы?
Sign up to leave a comment.
Кроссплатформенный код для приложений под iPhone и iPad