Скажу честно — не видел его ни разу, но судя по замечанию в оригинальной статье:
But on the whole this User Guide app and the PastryKit framework are rather amazing. The $64,000 question, though, is whether PastryKit is something Apple intends (or that a team within Apple hopes) to ship publicly. It seems like a lot of effort to build a framework this rich just for this iPhone User Guide, so I’m hopeful the answer is yes. Perhaps something integrated with the next major release of Dashcode? And, perhaps with integrated UI layout tools, along the lines of Interface Builder?
Спасибо за статью — всегда приятно узнать про имеющиеся открытые альтернативы. Смотрел месяца 3 назад на Cloud Made'овскую библиотеку, был неприятно поражен чужеродностью. Кругом бросалось в глаза явное портирование с Plain C (к примеру методы без именнованых параметров). Приведенный здесь код выглядит приятнее, хотя на отрисовку маршрута неплохо было бы посмотреть.
Незначительный вопрос/замечание по коду: после
BOOL toShow = [mapSourcePicker isHidden];
этот вызов используется еще пару раз. Это специально сделано? Потому что использование переменной вместо вызовов кажется предпочтительныи не только по соображениям производительности, но еще и читаемости.
Если пройти по любой ссылке из поста — сразу отпадет половина вопросов. И про проблемы с фиксацией, и про разницу в прокрутках и про устранение адресой строки (не только при запуске с десктопа) — весьма доходчиво написано. Сделать без библиотек можно вообще все — они же пользуются общедоступными средствами JS и CSS. Вопрос — надо ли самому пытаться переписать например систему View, чтобы веб-приложение выглядело нативно, если есть уже готоовая либа от Эппла?
Вот я тоже когда читал Ваш комментарий все думал про DirectFB (у нас просто Opera крутится именно в такой модификации внутри embedded-устройства). Почему уж сразу не оставить только DFB версию? И, даже если предположить что иксы можно почти везде, с чего это их везде нужно?
По поводу же самой новости — весь в недоумении. Выигрыш вижу только в уменьшении размера (приотказе от статически прилинкованного фреймворка), что на современном десктопе довод весьма сомнительный по-моему.
А вот чего они рискуют огрести — так это дополнительных багов при интеграции. Чисто для примера: на двухмониторной конфигурации combo-box'ы иногда выпадали не на том дисплее. Пользуешься большим фреймворком — авось за тебя пофиксят, но никто не мешает и самим патч предложить. А так все придется самим лечить (а ведь таких мелочей насобирать немало можно).
Ну когда я последний раз запускал Амарок (также третьей версии), тот умел синхронизировать многие айподы, но не Тач, и не айФон. А кроме них в хозяйстве уже ничего и не осталось. Еще под гномом был достаточно приятно-аскетичный плеер (он еще кажется умел подкасты синхронизировать) — та же фигня. Поскольку обе программы были мэйн-стримными — сделал вывод, что под линуксом с айФонами все плохо. Так 4-я версия Амарока все меняет? А то я присоединяюсь к оригинатору гневного вопроса :)
Вы меня похоже не понимаете, попробую с другой стороны. Если никогда не нужна ежемесячная группа (т.е. не отмеченно ни одной валюты и этой группы) — не тяните ее вообще. Если вопрос в том, что статистика меняется раз в месяц, а тянется каждый раз — запоминайте время операции и не тяните по напрасну. Пользователю безинтересны эти группы как таковые, их получение информации о конкретной валюте интересует. Не заставляйте их париться о выключении группы, которой они никогда не пользуются, и уж тем более париться о том, чтобы вовремя включить получение ежемесячной статистики. Вот приблизительно так бы я рассуждал на месте девелопера, хотя не исключаю, что не понимаю технических особенностей конкретно данной аппликухи.
я все понимаю о чем Вы написали. есть две группы, некоторых интересуют объекты из второй группы, дать мозможность отключать ненужные объекты — экономить траффик. мой вопрос был скорее об интересности самой группы для пользователя. хорошо представляю, о чем должен думать пользователь, чтобы захотеть шекелей, но совершенно не представляю о чем он должен думать чтобы захотеть «отключить доставку ежемесячных валют», например.
— возможность отображать только ежемесячные курсы валют, только ежедневные или и те и другие;
Правда ли существует, например, такой юз-кейс: «Хочу только ежемесячные курсы»? Просто я себе с трудом представляю, зачем может понадобиться дифференциация именно по этому признаку.
возможность отображать разницу с предыдущим курсом валют в процентах, просто предыдущее значение курса или разница в рублях.
Наверное дело вкуса, но я бы оставил только разницу (абсолютную и в процентах), причем с мозможностью выбора 2-х опция одновременно (т.е. скорее два чек-бокса, нежели один 3-позиционный радио-баттон). В смысле, правда есть юз-кейс: «Хочу видеть не разницу, а именно предыдущее значение»?
недавно вот на Жуйке поднимался вопрос о выборе текстового редактора для кодера. одним из важных критериев было «чтобы расширялся на таком-то языке».
ну вот наверное неплохая область для применения: встраиваемый язык для написания плагинов (возможно не требующих высокой производительности).
если бы расширения к TextMate'у например писались по заводу не на Ruby, а на Katahdin, то всяким прочим питонистам и пхп-шникам жилось бы проще: доставляешь модуль своего любимого языка и пишешь расширение удобное именно тебе, на хорошо известном тебе скриптовом языке.
Спасибо, все очень подробно рассписано; рецепту — путь в избранное. :)
Наверное только можно было бы еще тайтл и сабтайтл заменить на что-нибудь разумное (видимо между
Весьма любопытно, спасибо. У самого опыт работы с фреймворком не слишком большой, заметил несколько моментов для обсуждения, и буду рад комментариям.
На сколько я помню, при выбранном подходе NSNotification было бы использовать удобнее в случае нескольких получателей уведомления об изменении состояния модели.
Общеприянтой практикой, как я понял, является объявление подобных Model сущностей в Application Delegate, с дальнейшим осуществлением доступа через sharedApplication. Т.е. одного синглтона (предоставляемого приложением) казалось бы достаточно, и вводить новые — избыточно.
Такое ощущение, что доставка подобного рода уведомлений обычно осуществляется несколько по-другому: к сеттеру совйства прикручивается вызов метода, описываемого в протоколе соответствующего делегата. Все заинтересованные в уведомлениях сущности (обычно контроллеры) после получения доступа к разделяемой сущности (свойства sharedApplication) добавляют себя в список делегатов (тоже ничего писать не нужно, какой-то стандартный метод типа addDelegate есть). Реализуя необходимое подмножество протокольных методов получаем необходимые нотификации. В качестве бонуса: общая логика связанная с уведомлениями может быть релизована на стороне источника, а в методы делегата передается уже результат. Такой механизм представляется более очевидным, чем KVO или использование NSNotification.
Интересно, но если использовать coLinux только для доступа к ФС (и тем более запускать его как сервис), то по-моему лучше использовать не предпочитаемый дистрибутив, но почти голое ядро, причем еще и облегченное по-максимуму (оставить сеть + драйвера ФС). Также можно попробовать обойтись без самбы вовсе, а из винды доступаться к дискам через ssh (NetDrive'ом например), возможно еще и скорость вырастет.
Тем, кому идея управлять микро-блогами при помощи мессенджера кажется привлекательной, но по каким-либо причинам еще не добравшимся до жуйка — рекомендую juick.com.
Там изначально так задумано, что никаких шлюзов не нужно, и авторизация осуществляется путем добавления бота в контакт-лист. Правда сервиса по «сжатию/разжатию ссылок» там никогда не будет :)
Преимущества джаббера перед ICQ на хабре уже расписаны сто раз, главные примущества жуйка перед тви: отсутствие ограничений на размер поста, разделение сообщений на посты и комментарии к ним (и прочие мелкие плюшки, типа интеграции медиа- и геолокационных данных)
P.S. Для людей жестко привязанных к твиттеру предлженный сервис будет, безусловно, полезен. Спасибо за труды :)
видимо не все так хорошо…
Незначительный вопрос/замечание по коду: после
этот вызов используется еще пару раз. Это специально сделано? Потому что использование переменной вместо вызовов кажется предпочтительныи не только по соображениям производительности, но еще и читаемости.
По поводу же самой новости — весь в недоумении. Выигрыш вижу только в уменьшении размера (приотказе от статически прилинкованного фреймворка), что на современном десктопе довод весьма сомнительный по-моему.
А вот чего они рискуют огрести — так это дополнительных багов при интеграции. Чисто для примера: на двухмониторной конфигурации combo-box'ы иногда выпадали не на том дисплее. Пользуешься большим фреймворком — авось за тебя пофиксят, но никто не мешает и самим патч предложить. А так все придется самим лечить (а ведь таких мелочей насобирать немало можно).
DISPLAY=:0 rhythmbox-client --next
Правда ли существует, например, такой юз-кейс: «Хочу только ежемесячные курсы»? Просто я себе с трудом представляю, зачем может понадобиться дифференциация именно по этому признаку.
Наверное дело вкуса, но я бы оставил только разницу (абсолютную и в процентах), причем с мозможностью выбора 2-х опция одновременно (т.е. скорее два чек-бокса, нежели один 3-позиционный радио-баттон). В смысле, правда есть юз-кейс: «Хочу видеть не разницу, а именно предыдущее значение»?
ну вот наверное неплохая область для применения: встраиваемый язык для написания плагинов (возможно не требующих высокой производительности).
если бы расширения к TextMate'у например писались по заводу не на Ruby, а на Katahdin, то всяким прочим питонистам и пхп-шникам жилось бы проще: доставляешь модуль своего любимого языка и пишешь расширение удобное именно тебе, на хорошо известном тебе скриптовом языке.
Наверное только можно было бы еще тайтл и сабтайтл заменить на что-нибудь разумное (видимо между
и
можно устанавливать свойтва аннотации)
На сколько я помню, при выбранном подходе NSNotification было бы использовать удобнее в случае нескольких получателей уведомления об изменении состояния модели.
Общеприянтой практикой, как я понял, является объявление подобных Model сущностей в Application Delegate, с дальнейшим осуществлением доступа через sharedApplication. Т.е. одного синглтона (предоставляемого приложением) казалось бы достаточно, и вводить новые — избыточно.
Такое ощущение, что доставка подобного рода уведомлений обычно осуществляется несколько по-другому: к сеттеру совйства прикручивается вызов метода, описываемого в протоколе соответствующего делегата. Все заинтересованные в уведомлениях сущности (обычно контроллеры) после получения доступа к разделяемой сущности (свойства sharedApplication) добавляют себя в список делегатов (тоже ничего писать не нужно, какой-то стандартный метод типа addDelegate есть). Реализуя необходимое подмножество протокольных методов получаем необходимые нотификации. В качестве бонуса: общая логика связанная с уведомлениями может быть релизована на стороне источника, а в методы делегата передается уже результат. Такой механизм представляется более очевидным, чем KVO или использование NSNotification.
Там изначально так задумано, что никаких шлюзов не нужно, и авторизация осуществляется путем добавления бота в контакт-лист. Правда сервиса по «сжатию/разжатию ссылок» там никогда не будет :)
Преимущества джаббера перед ICQ на хабре уже расписаны сто раз, главные примущества жуйка перед тви: отсутствие ограничений на размер поста, разделение сообщений на посты и комментарии к ним (и прочие мелкие плюшки, типа интеграции медиа- и геолокационных данных)
P.S. Для людей жестко привязанных к твиттеру предлженный сервис будет, безусловно, полезен. Спасибо за труды :)