В вашем маппере нравится в первую очередь простота. Но по ходу это единственный его плюс. А теперь о том, что не нравится:
1) Модель уже не модель
Теперь у неё есть методы для парсинга объектов и методы для настройки этих методов. И они будут с ней в памяти навсегда.
Здесь мне больше всё же нравится подход управления моделью снаружи.
2) Необходимость создавать модели даже для всех вложенных объектов.
Если данные какого-то json объекта разбиты на несколько групп для простоты их понимания, то я не хочу создавать одну общую модель и несколько вложенных. В этом случае я хочу иметь одну модель и для её свойств указать пути для получения значений. Ну или что-то в этом роде.
Самое меньшее, что здесь нужно реализовать – добавить возможность хранить вложенный объект в виде словаря без принудительного парсинга. Тогда хотябы костылями можно добиться нужного поведения в сложных случаях.
Упомянутый выше JTObjectMapping по моему мнению хуже вашего в виду необходимости явно указывать поля для маппинга. А я же в качестве более навороченной альтернативы могу упомянуть github.com/dchohfi/KeyValueObjectMapping. Кроме описанной мной выше необходимости создавать одну модель из нескольких объектов он сможет делать и противоположную вещь – создавать несколько вложенных моделей на основе плоских данных.
Очень хотелось бы иметь возможность отсортировать фильмы по количеству кинотеатров, в которых они идут. Такая сортировка позволит сразу видеть актуальные и новые фильмы.
Альтернативой может быть сортировка по дате выхода в украинский прокат.
Разбирался с гидрой (тогда это ещё так называлось) ещё во времена её беты (почти два года назад). И очень жаль, что с того времени ничего и не поменялось.
По началу очень сложно перестроить своё мышление: перестать думать о целом изображении и начать думать со стороны одного пикселя – это первое время вгоняет в ступор. Но въехав понял, что возможности очень и очень ограничены. Написать простенький фильтр по цветам – легко (но так же легко и без бендера), а вот что-то более сложное (например, motion blur) уже требует хотябы банальных циклов.
Самое хорошее применения бендеру – в трёхмерных движках для шейдинга и текстурирования. В остальных случаях для меня это как баловство – редко требуется в реальных задачах. Хотя, хорошо зная математику, и перестроив мышление – можно делать красиво. Например, как здесь: www.adobe.com/cfusion/exchange/index.cfm?event=productHome&exc=26
Если у тебя есть слой, который тебе нужен для разработки, но при коприляции не нужен — то просто делаешь его гайдом. Например скриншот будущей флэшки, чтобы по нему расставлять элементы. Или слой, на котором лежат мувики, которые потом будут добавляться на сцену динамически. Или какойто мувик, который нужно убрать из флэшки, но он еще может понадобиться в будущем.
Гайды не компилируются в свфку, поэтому в них можно сувать любые штуки.
Но при очиске библиотеки — мувики, лежащие на гайдах считаются используемыми и не удалятся.
В общем сделать слой гайдом — всёравно, что скрыть его из свфки.
А вот про то, что так категорически делать нельзя, написано здесь уже несколько постов. Тем более от этого свфка становится больше в виду многократного дублирования одинаковых символов. И текст после этого невозможно отредактировать.
Про пути не замечал, так как в обоих сиудиях, где я работал, guide'ами пользуются только для скрытия слоёв. И чтото даже не верится в то, что они отваливаются — надо будет попробовать.
А layer manager справляется отлично с любыми слоями. Но у него есть один бок — он ставит ноль нового мувика в центре, а это не всегда удобно. А вообще скачай и попробуй — он бесплатный.
Не вижу проблем, независимо от количества кадров и слоёв:
Выделяем все кадры во всех слоях, кликаем правой кнопкой на любой кадр, выбираем copy frames, удаляем все эти кадры, создаём новый мувиклип, в нём paste frames, кладём этот мувик на уже пустую сцену. В чём проблема?
Либо ещё проще — ставим jsfl плагин layer manager (вроде такое у него название) и в нём это делаем за 5 секунд.
а чего вдруг «Apple не разрешает» в заголовке?
На сколько я понял из данных конференции — apple просто ещё не приняло окончательное решение и взвешивает всё.
я бы стремался разрешать флэш на айфоне. как минимум из соображений производительности. многие флэшки смогут спокойно подвесить айфон.
мне на самом деле больше интересно, какую версию плеера (в смысле аналог какой версии плеера для компа) портировали на айфон. если хотябы девятку или на крайний случай восьмёрку — то я жду момента выхода с огромным нетерпением. если ниже, то нафиг он нужен. будет как флэшлайт — мёртвый.
Эта команда делает следующее: сохраняет флашку в тэмпе с темповым именем, после чего твою реальную флашку удаляет и записывает на её место флашку из темпа.
То есть грубо говоря делает просто save as… в новый файл. Именно эта команда и убирает весь мусор. Потому, что флашка пишется с нуля.
В случае же обычного save идёт дописывание флашки. И этот процесс не удалит ваши 40 мегабайт видео. Зато произойдёт очень быстро и без глюков.
Но с другой стороны save and compact, в случае глюка на процессе замены вашего старого файла новым, может побить вашу флашку на всегда.
Поэтому лучше всего в случае желания сжать флашку — использовать save as… в файл с новым именем.
Так если это сборка андройда для HTC Vogue (как у написано у автора в первой строчке), то, может, кто-то знает, можно ли вообще теоретически сделать таковую под HTC Touch?
Очень классная статья!
Толкает меня на то, чтобы серьёзно поменять свой образ жизни.
В основном благодаря тому, что вы описали причины, по которым мне нужно отказаться от одних действий в пользу других. Это очень важно.
Надеюсь, что смогу изменить свой режим.
1) Модель уже не модель
Теперь у неё есть методы для парсинга объектов и методы для настройки этих методов. И они будут с ней в памяти навсегда.
Здесь мне больше всё же нравится подход управления моделью снаружи.
2) Необходимость создавать модели даже для всех вложенных объектов.
Если данные какого-то json объекта разбиты на несколько групп для простоты их понимания, то я не хочу создавать одну общую модель и несколько вложенных. В этом случае я хочу иметь одну модель и для её свойств указать пути для получения значений. Ну или что-то в этом роде.
Самое меньшее, что здесь нужно реализовать – добавить возможность хранить вложенный объект в виде словаря без принудительного парсинга. Тогда хотябы костылями можно добиться нужного поведения в сложных случаях.
Упомянутый выше JTObjectMapping по моему мнению хуже вашего в виду необходимости явно указывать поля для маппинга. А я же в качестве более навороченной альтернативы могу упомянуть github.com/dchohfi/KeyValueObjectMapping. Кроме описанной мной выше необходимости создавать одну модель из нескольких объектов он сможет делать и противоположную вещь – создавать несколько вложенных моделей на основе плоских данных.
Альтернативой может быть сортировка по дате выхода в украинский прокат.
По началу очень сложно перестроить своё мышление: перестать думать о целом изображении и начать думать со стороны одного пикселя – это первое время вгоняет в ступор. Но въехав понял, что возможности очень и очень ограничены. Написать простенький фильтр по цветам – легко (но так же легко и без бендера), а вот что-то более сложное (например, motion blur) уже требует хотябы банальных циклов.
Самое хорошее применения бендеру – в трёхмерных движках для шейдинга и текстурирования. В остальных случаях для меня это как баловство – редко требуется в реальных задачах. Хотя, хорошо зная математику, и перестроив мышление – можно делать красиво. Например, как здесь: www.adobe.com/cfusion/exchange/index.cfm?event=productHome&exc=26
Гайды не компилируются в свфку, поэтому в них можно сувать любые штуки.
Но при очиске библиотеки — мувики, лежащие на гайдах считаются используемыми и не удалятся.
В общем сделать слой гайдом — всёравно, что скрыть его из свфки.
А layer manager справляется отлично с любыми слоями. Но у него есть один бок — он ставит ноль нового мувика в центре, а это не всегда удобно. А вообще скачай и попробуй — он бесплатный.
Выделяем все кадры во всех слоях, кликаем правой кнопкой на любой кадр, выбираем copy frames, удаляем все эти кадры, создаём новый мувиклип, в нём paste frames, кладём этот мувик на уже пустую сцену. В чём проблема?
Либо ещё проще — ставим jsfl плагин layer manager (вроде такое у него название) и в нём это делаем за 5 секунд.
На сколько я понял из данных конференции — apple просто ещё не приняло окончательное решение и взвешивает всё.
я бы стремался разрешать флэш на айфоне. как минимум из соображений производительности. многие флэшки смогут спокойно подвесить айфон.
мне на самом деле больше интересно, какую версию плеера (в смысле аналог какой версии плеера для компа) портировали на айфон. если хотябы девятку или на крайний случай восьмёрку — то я жду момента выхода с огромным нетерпением. если ниже, то нафиг он нужен. будет как флэшлайт — мёртвый.
То есть грубо говоря делает просто save as… в новый файл. Именно эта команда и убирает весь мусор. Потому, что флашка пишется с нуля.
В случае же обычного save идёт дописывание флашки. И этот процесс не удалит ваши 40 мегабайт видео. Зато произойдёт очень быстро и без глюков.
Но с другой стороны save and compact, в случае глюка на процессе замены вашего старого файла новым, может побить вашу флашку на всегда.
Поэтому лучше всего в случае желания сжать флашку — использовать save as… в файл с новым именем.
Толкает меня на то, чтобы серьёзно поменять свой образ жизни.
В основном благодаря тому, что вы описали причины, по которым мне нужно отказаться от одних действий в пользу других. Это очень важно.
Надеюсь, что смогу изменить свой режим.