Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Регистрация Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Блоги > fish_r

Рейтинг: 5.00. Голосов: 2.

Odnoklassniki.API 2.0 photo upload V2

Запись от fish_r размещена 09.06.2012 в 11:28
Обновил(-а) fish_r 10.01.2015 в 01:01

В апреле (2012) запущено новое АПИ ОК для загрузки фотографий в альбом пользователя. Собственный SDK для AC 3.0 Одноклассников реализует, пока, старый метод. Весьма вероятно, что к новым приложениям будет предъявляться требование upload-a с использованием нового метода, т.к. старый создает нагрузку на дата-сервера пересылая данные через них, новый же загружает изображения уже прямо на имидж-серверы. Во всяком случае мне пришлось отказаться от использования старого АПИ, в этой части, и по требованию со стороны ОК написать аплоад с использованием нового АПИ.

Собственно плагин для нового метода загруки и есть предмет этой записи. Документация к нему есть, там, вроде, сказано достаточно. Хочу заметить, лишь, что в оригинальной версии приложения для выведения хеш-подписи запроса, десериализации JSON-а, и кодирования фото в формат jpg использовалась известная библиотека BlooDHounD-a, но из за того, что в приложениях скомпилированных под 11-ый и выше плеер она работать не будет в этой версии пришлось подключить соотв. классы из пакета api.com.adobe..., которые есть в стандартном SDK API Odnokassniki, правда эту или какую либо другую библиотеку для кодирования изображения использовать по прежнему можно, только, теперь, не как внутренний компонент, а как внешний ( см. доки ). Для работы плагина сдк, конечно, должно быть включено в проект...

Пример использования:

Код AS3:
 
 package 
        {
            import flash.display.Bitmap;
            import flash.display.BitmapData;
            import flash.display.Sprite;
            import flash.display.StageAlign;
            import flash.display.StageScaleMode;
            import flash.events.Event;
            import su.fishr.social_network.OK.uploadV2.DataPhoto;
            import su.fishr.social_network.OK.uploadV2.UploaderPhotoV2;
 
 
            public class Main extends Sprite 
            {
                /// гл. класс приложения
                public function Main():void 
                {
                    if (stage) init();
                    else addEventListener(Event.ADDED_TO_STAGE, init);
                }
 
                ///инициализация
                private function init(e:Event = null):void 
                {
                    removeEventListener(Event.ADDED_TO_STAGE, init);
                    // entry point
 
                    this.stage.scaleMode = StageScaleMode.NO_SCALE;
                    this.stage.align = StageAlign.LEFT;
 
                    /// в качестве примера отрисовываем сцену в массив BitmapData
                    const bData:BitmapData = new BitmapData( this.stage.stageWidth, this.stage.stageHeight, false );
                    bData.draw( this );
 
                    /// создаем объект Bitmap
                    const bt:Bitmap = new Bitmap( bData );
 
                    /// создаем структурированный объект dataPhoto
                    const dataPhoto:DataPhoto = new DataPhoto( callBack, bt, "this is me", "myPhoto" );
 
                    /// начинаем загрузку фотографии (изображения)
                    new UploaderPhotoV2( dataPhoto, this.loaderInfo.parameters );
                }
 
                /// сюда будет возвращен результат загрузки
                private function callBack( result:String ):void
                {
                    switch ( result ) 
                    {
                        case UploaderPhotoV2.ANOTHER_ERROR :
                            trace( "what the error ( " );
                            /// some action
                        break; 
 
                        case UploaderPhotoV2.NO_BODY_PHOTO:
                            trace( "no photo (" );
                            /// another action
                        break;
 
                        case UploaderPhotoV2.NO_ACCESS_PHOTOALBUM:
                            trace( "Please give access to the album!" );
                        break;
 
                        default:
                            trace( "Congratulations! Your photo added in album!");
 
 
                    }
                }
 
            }
 
        }
Сорцы
Всего комментариев 25

Комментарии

Старый 10.06.2012 01:13 Psycho Tiger вне форума
Psycho Tiger
 
Аватар для Psycho Tiger
Здорово, спасибо!
Только не очень здорово, что простой callback. Куда приятней использовать событие для таких штук.
Старый 10.06.2012 09:30 fish_r вне форума
fish_r
 
Аватар для fish_r
а. да. Ты прав. Этот и другие недостатки ( "бедность палитры" ошибок, отсутствие реализации серийной загрузки...) имеют место быть. Дело в том, что это писалось под требования конкретной среды, а не с целью "международного признания" ) Это, может быть, не очень хорошо, но "чем богаты...". Впрочем с каллбэками лечится легко, как снаружи так и внутри.

У этого скрипта есть ещё одна полезная, и может быть более важная, сторона. Это демонстрация очень простой, на мой взгляд, модели общения с АПИ ОК. Мне лично очень помогают простые и работающие примеры вместо пространных/заумных/неграмотных/невнятных/неполных ( нужное подчеркнуть ) хелпов сервисов, для освоения различных техник и технологий взаимодействия с ними (сервисами). Даже если всё понятно написано, ты всё равно чувствуешь некоторую неуверенность сначала потому, что не знаешь что декларативно, а что работает на самом деле.

PS. Мне бы и в голову не пришло публиковать что то подобное, если бы речь шла об вк или facebook, по ним есть много материалов, да и вообще там как то всё яснее. По ОК-же всего очень мало и на флешере, и в нете, и собственно на ОК...
Обновил(-а) fish_r 10.06.2012 в 10:03
Старый 10.06.2012 19:12 TanaTiX вне форума
TanaTiX
 
Аватар для TanaTiX
Цитата:
Только не очень здорово, что простой callback.
А мне как раз колбэки последнее время нравятся больше. Особенно в тех случаях, когда нет необходимости использования всех примочек событийной модели.
Старый 11.06.2012 07:48 Psycho Tiger вне форума
Psycho Tiger
 
Аватар для Psycho Tiger
А в чем разница? Подписались - отписались, это 2 строчки кода. Только события куда более гибкие, расширяемые и безгеморойно-устойчивые.
Старый 11.06.2012 12:02 TanaTiX вне форума
TanaTiX
 
Аватар для TanaTiX
Psycho Tiger, а в чем геморрность колбэков? Передали метод в сеттер (считай подписались), нужна отправить событие - запустил необходимый метод (считай продиспатчили событие), нужно удалить - в сеттер передали null (считай отписались) Нужно передать какие-то параметры - вот тут уже можно задуматься о событиях, хотя колбэки с этим тоже элементарно справляются, хотя может и не так прозрачно. Я не хочу сказать, что события - плохо, но их функционал зачастую излишен, когда речь идет о кастомных событиях, когда тип события особого значения не имеет.
Старый 11.06.2012 16:17 fish_r вне форума
fish_r
 
Аватар для fish_r
Цитата:
в чем геморрность колбэков?
По мне так - иногда не очевидно откуда передан калбэк, и кто же заинтересованный объект? Иногда трудно определить момент - когда в недисплай обжекте занулить калбэк, чтобы объект на метод которого он ссылается не повис в памяти мертвым грузом...

Если бы в результате работы загрузчика фотографий, в моей конкретной флешке, было заинтересовано несколько объектов, или если бы я сразу писал "на публику" я бы сделал событие, или события. Просто в данном конкретном случае я обходил проблему отсутствия event flow в не экранных объектах, т.к. в результате был заинтересован только "какой-то там" subsubviewer а инициализировал загрузку "какой-то там" subsubprovider...
Старый 12.06.2012 10:39 Psycho Tiger вне форума
Psycho Tiger
 
Аватар для Psycho Tiger
@TanaTiX, вот есть весьма стандартизированный подход для флеша - события. Вместо этого ты лепишь непонятную мурду со своими коллбеками, хотя количество написанного тобой кода только возрастет (за счет проверок на null'ость переменной callback'a).

Гемморой начинается тогда, когда в такой структуре "вдруг" нужно добавить второго подписчика. Или передать параметр. Или определить, дёрнул метод именно твой коллбек, или кто-то тупо дёрнул хэндлер. Я уже не говорю о бабблинге, когда понадобится легко "уведомить" вышестоящих. А когда у тебя будет 2 коллбека - случай будет решать, какой коллбек вызвать первым?

Подобная дергатня методов разве что работает быстрее. Поэтому если у тебя 100 раз в секунду такой метод дёргается - да, просто вызывай метод. В противном случае рекомендую обезопасить себя на будущее запасом на расширение программы.
Старый 12.06.2012 15:56 TanaTiX вне форума
TanaTiX
 
Аватар для TanaTiX
Повторюсь
Цитата:
...когда нет необходимости использования всех примочек событийной модели.
Я не против событий, но я и не против колбэков там, где они оправданы. Вряд ли у меня когда-то появится желание реализовать полноценное приложение исключительно на колбэках. Инструменты можно использовать разные, но и пользоваться ими тоже необходимо уметь. С другой стороны, если умеешь пользоваться чем-то одним - лучше пользоваться этим. Применение инструментов, которыми не умеешь пользоваться, может привести к печальным последствиям.
Старый 13.06.2012 12:06 Psycho Tiger вне форума
Psycho Tiger
 
Аватар для Psycho Tiger
Всё просто: дают примочки - бери.
Старый 13.06.2012 14:02 udaaff вне форума
udaaff
Я за единообразие кода. Если пользуемся событиями, давайте пользоваться событиями, и ничего не "упрощать" таким вот способом.
Старый 14.06.2012 22:08 Inet_PC вне форума
Inet_PC
А, ну да, из ракеты по воробьям. Единственный недостаток callback-ов в AS3 - это отсутствие возможности указать сигнатуру (ну и перегрузка функций тоже не хватает). Callback-и быстрее (сами Adobe советует, хотя и так понятно). Если нужно много обработчиков (не в будущем, когда-то возможно потребуется, ну мало-ли, а действительно использование здесь и сейчас), то события. Иначе callback. В таких сервисах вообще не понятно при каких обстоятельствах может потребоваться много подписчиков. Ну, запросили Вы список друзей, и что все приложение будет подписываться на это событие? Бред. Ну приведите мне пример, когда вдруг нужно добавить события к такому сервису?
Цитата:
А в чем разница? Подписались - отписались, это 2 строчки кода. Только события куда более гибкие, расширяемые и безгеморойно-устойчивые.
Зачем все вокруг бегуют за этой расширяемостью. Это все мертвый код. Не возможно написать все максимально расширяемо-настраевомо (да и еще и надеятся, что там будет меньше ошибок). Про то, что это неэффективно я молчу. Нужно стараться найти грань. Flex тоже расширяем и все такое, возможно там тоже все началось со подобного высказывания. (Естественно это все мое имхо и к восстанию не призываю).
Обновил(-а) Inet_PC 14.06.2012 в 22:10
Старый 14.06.2012 22:31 ChuwY вне форума
ChuwY
 
Аватар для ChuwY
Цитата:
Ну, запросили Вы список друзей, и что все приложение будет подписываться на это событие?
Что странного в том, чтобы обновить список друзей\баланс\прочую инфу сразу в нескольких местах?
Старый 14.06.2012 23:01 Inet_PC вне форума
Inet_PC
Да в общем ничего... Но почему всякие кнопочки, списки, боксы и тд. должны что-то знать о сервисе? Они всего лишь отображают ифну и им должно быть без разницы откуда она взялась (из соц сервиса или из локального файла). Разве нет? Ну я себе это вижу так. По какому-то событию (например пользователь щелкнул по кнопке) отправляется запрос (вызов метода сервиса), а в callback-е обновляем модель и все кому нужно обновятся. Зачем всем слушать сервис? Может, при определенных обстоятельствах, при вызове метода не нужно сразу обновлять инфу, и что весь проверочный код (нужно щас обновлять или нет) рассовывать по всем подпискам? И вместо одной подписки на модель у нас появляется еще одна на сервис, зачем?
Старый 14.06.2012 23:54 udaaff вне форума
udaaff
Из ракеты... с ядерной боеголовкой может еще? В том то и дело, что нужно уметь находить грань, а не кидаться в крайности, в погоне за абсолютно не значительным, а в данном случае и не нужным, увеличением производительности.
Старый 15.06.2012 00:43 Inet_PC вне форума
Inet_PC
Да дело не только в производительности. Вы же мебельные гвозди кувалдой не забиваете, так ведь.
Цитата:
Я за единообразие кода. Если пользуемся событиями, давайте пользоваться событиями, и ничего не "упрощать" таким вот способом.
Это не называется нашел грань. Я же не говорю, что события не нужны. Всему свое место. Я думаю это и есть грань.
Старый 15.06.2012 07:51 fish_r вне форума
fish_r
 
Аватар для fish_r
Inet_PC абсолютно солидарен с твоей (могу на ты?) точкой зрения на использование калбэков. Что то странное, и от религии, есть в обете "не использовать калбэки никогда и ни за что", тем более странно, что их использование, якобы, должно негативно влиять на расширяемость приложения - да ни разу! Анонимность калбэков как нельзя лучше влияет на расширяемость, вот на отлаживаемость плохо - это да.

Цитата:
Зачем все вокруг бегуют за этой расширяемостью. Это все мертвый код. Не возможно написать все максимально расширяемо-настраевомо (да и еще и надеятся, что там будет меньше ошибок).
Не согласен. Очень большую часть ( ну процентов 70 или более) проектов приходиться расширять как в ходе создания, так и спустя некоторое время ( иногда даже год и более ), причем спустя время - чаще. Поэтому для меня, например, расширяемость и слабая связанность объектов в приложении - приоритетнейшие насущные задачи, а не теоретические измышления. Дополнения в проектах оплачиваются хорошо ( лучше чем просто написание), а реальные трудозатраты зависят от того насколько удачна архитектура приложения с этой точки зрения.
Обновил(-а) fish_r 15.06.2012 в 08:18
Старый 15.06.2012 09:50 udaaff вне форума
udaaff
А я так и не понял, в чём профит использования огорода с коллбеками в данном случае, и почему события обзывают кувалдой.
Старый 15.06.2012 11:01 Psycho Tiger вне форума
Psycho Tiger
 
Аватар для Psycho Tiger
Помню, работал над проектом (кстати, с ChuwY и с udaaff'ом) - и к нам пришел ещё один кодер, который тоже считал, что события - "слишком тяжелые". Только он ещё считал, что обычные callback'и - слишком лёгкие. Поэтому он к уже работающей системе начал лепить слот-сигнал - он ему больше нравился. Доходило до того, что отправлял событие, а следующей строкой - такой же сигнал. С бОльшим поносом в коде я в жизни не работал.

Это пошла бездумная мода на "я умею пользоваться и могу даже объяснить, зачем".
Но я всё же попробую:
Плюсы событий:
1) множество слушателей
2) возможность определения источника события
3) возможность передачи параметра
4) возможность бабблинга, capture-фазы

Когда эти 4 пункта не нужны - события дают расширяемость. Когда они понадобятся на тупых callback'ах - они у меня уже будут. А вы будете ломать голову, как бы их добавить / перейти на события.

А если они и не появятся - вот то, что всегда хорошо:
1) наличие weak-reference
2) известная заранее сигнатура хэндлера

И 2 самых важных, которые очень повышают читаемость кода.
3) Вытекает из пункта №2: если параметр в методе типа Event - это - handler
И, самое важное:
4) Почти все подписки происходят на методы этого класса. Очень редко хэндлером выступает метод стороннего экземпляра (item.something.update). Это означает, что я ВСЕГДА могу сказать, почему этот метод вызван (потому что сработало такое-то событие у такого-то экземпляра). Да могу хоть поиском с строкой события пройти по всему проекту и ещё до дебага понять, кто-же мог отослать такое событие.

С callback'ами же я вообще никогда не могу быть уверен, почему какой-то метод был когда-то кем-то вызван и вообще на каком основании. Смотреть, кто мог переопределить ссылку, кому передали ссылку на ссылку на ссылку на метод? Нет, я правда не вижу это удобным молотком для гвоздей.

Плюсы callback'ов:
1) Они быстрее на миллионе итераций.
2) Можно похвастаться коллегам, что вы не хипстер и не пользуетесь мейнстримом.
Старый 15.06.2012 11:14 fish_r вне форума
fish_r
 
Аватар для fish_r
Цитата:
А я так и не понял, в чём профит использования огорода с коллбеками в данном случае, и почему события обзывают кувалдой.
"В данном случае" - это в каком? Если мы рассматриваем представленный код отдельно от какого либо контекста, то профит сомнительный, это даже не верное решение, в свое оправдание могу сказать лишь то, что весь SDK ОК построен на калбэках, так что для единообразия?
В контексте приложения в котором он работал это было выигрышным решением, т.к. результаты выгрузки интересовали объект который не имел ссылок ни на провайдер ни на контроллер, верно и обратное - ни провайдер, ни контроллер не имели ссылок на заинтересованный объект. И вот, чтобы не городить огород
с декларированием события, подпиской на него, отлавливанием, отпиской ( и это надо было бы повторить не один раз, чтобы через цепочку не заинтересованных объектов передать информацию целевому) я и сделал калбэк, и до сих пор об этом не жалею.
Обновил(-а) fish_r 15.06.2012 в 11:19
Старый 15.06.2012 14:06 TanaTiX вне форума
TanaTiX
 
Аватар для TanaTiX
И у колбэков, и у событий есть свои и плюсы и минусы. Как я уже писал, каждый будет пользоваться тем, что ему больше нравится (с помощью чего лучше/быстрее/красивее/аккуратнее получается). К чему пипи***** меряться? Необходимость использования каждого способа будет все равно зависеть от конкретной задачи и предпочтений программиста. Универсального решения не существует. Спор пошел ни о чем.
Старый 18.06.2012 00:03 dimarik вне форума
dimarik
 
Аватар для dimarik
А почему библиотека Блуда не будет работать под -swf-version=13 и выше (11.0 плеер и выше)?
Старый 18.06.2012 12:31 etc вне форума
etc
 
Аватар для etc
Потому что Alchemy.
Старый 18.06.2012 14:28 Stitch512 вне форума
Stitch512
Ну вообще то будет работать, у меня в проекте stage3d параллельно используется с bloddy_crypto. Только есть момент, что при использовании stage3d api и Alchemy одновременно, нужно платить 9% адобу, еслии доход от приложения >50000$
Старый 25.06.2012 22:42 dimarik вне форума
dimarik
 
Аватар для dimarik
Вот оно шо, Дениска )
Valyard, тут намедни, на FlasGamm допытывал ихнево евангелиста на предмет того, как будут отслеживать эти $50к+. Тот сказал, что если найдем, то покараем!
Обновил(-а) dimarik 25.06.2012 в 22:48
Старый 27.06.2012 19:18 gloomyBrain вне форума
gloomyBrain
 
Аватар для gloomyBrain
Цитата:
Ну вообще то будет работать, у меня в проекте stage3d параллельно используется с bloddy_crypto. Только есть момент, что при использовании stage3d api и Alchemy одновременно, нужно платить 9% адобу, еслии доход от приложения >50000$
В blooddy_crypto не та алхимия, на которую Adobe накладывают ограничения. Точнее говоря - версия не та. Первая версия алхимии тупо не будет работать в следующих версиях плеера. Вместо нее Adobe предлагает новую, еще более алхимическую алхимию (2-ой версии), которая как раз является премиум-фичей и, соответственно, облагается налогом.

Стоит также добавить, что в blooddy_crypto тот же json не использует никакой алхимии. Так что сам факт наличия данной swc в проекте не обязательно приводит к использованию сакральных опкодов.
Обновил(-а) gloomyBrain 27.06.2012 в 19:21
 

 


Часовой пояс GMT +4, время: 20:06.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2022, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.