Абсолютно не согласен, что мой доклад был повторен. Просто первый доклад был посвящен решению проблем с которыми я столкнулся при использовании dagger2. А второй доклад рассказывает зачем вообще нужен этот DI и dagger2. И я об этом в самом начале второго доклада сказал.
Вообще я хотел на втором докладе еще сильнее окунуться в хардкор, в тестирование с DI. Но по вопросам на mobile camp понял, что надо начать с более фундаментальных вещей.
И учтите, что для большинства устройств может быть запущено только два OMXCodec инстанса на процесс. Т.е. вы не можете в одном окне проиграть больше двух видео одновременно.
В рамках android framework, мы можете принудительно создать MediaCodec который будет работать на софтверном гугловом декодере и вот на нем уже проигрывать несколько видео в окне.
Vitamio у себя юзают тот же OMXCodec, который через хак добывают.
Проблемы с нестабильностью MediaPlayer связаны с вендорами, которые могут нестандартно реализовать свои кодеки, яркий пример — Allwinner.
Из фреймворков для мультимедиа могу порекомендовать github.com/google/ExoPlayer. На последнем Google IO в секции про Android TV главный разработчик сего фреймворка про него рассказывал.
ExoPlayer внутри использует MediaCodec API.
Да, как из приложение для android можно добраться до декодера (OMX).
Кстати, у MediaPlayerService в с++ части есть метод getOMX (пример как использовать).
И вы всегда можете его получить с 2.3.
Небольшое уточнение, в Android за декодирование отвечает OMX (OpenMAX IL, если быть точным). Stagefright это гугловый плеер, который реализован при помощи OMX. Помимо stagefright для RTSP и HLS используется NuPlayer.
Т.е. копать вам надо в сторону OMX. Но и не все производители снабжают свои устройства OMX плагинами. Яркий пример — Allwinner. У них свой плеер и свой медиа стек.
Если речь идет об ондроеде, то:
Можете посмотреть «простой» пример из ffmpeg. Там куча багов, работает не на всех устройствах (проблемы с цветом или некорректная инициализация декодера)
Затем можно заглянуть в код XBMC, VLC и в последний gstreamer (самый взрослый код из всех открытых проектов).
На всякий случай (вдруг кто не знает), как обходное решение и для таких вот редакторов в своем кастомном контроле, все кастомное можно завернуть в if (!isInEditMode()) { кастомный код }. Ну и CustomTextView будет видится как обычный TextView в таких редакторах.
При первом запросе создается SQL statement, а дальше при заполнении окна вызывается sqlite3_step.
Как видите, эта схема поддерживается на уровне самого sqlite. Никаких доп. запросов он не делает.
И мои пять копеек к orm for android: ActiveAndroid (Active record style SQLite persistence for Android). Это уже конечно более высокий уровень по сравнению с курсором, и подгрузка данных происходит тогда когда она нужна, НО в андроиде этот подход опять же не оправдан, т.к. здесь везде хотят курсор, и кто его знает как эти все ORM монстры «запоют» на каком-нибудь huawei ideos :). В отличии от Android, в iOS ActiveRecord подход оправдан, там хотя бы железо всегда адекватное.
Я имел ввиду один из способов работы с БД, а именно использование сторонней библиотеки в которой уже почти все есть =). Конечно, лучше наверно сразу использовать какой-нибудь ormlite, но все же.
но там не все доклады есть :(
Вообще я хотел на втором докладе еще сильнее окунуться в хардкор, в тестирование с DI. Но по вопросам на mobile camp понял, что надо начать с более фундаментальных вещей.
В рамках android framework, мы можете принудительно создать MediaCodec который будет работать на софтверном гугловом декодере и вот на нем уже проигрывать несколько видео в окне.
Проблемы с нестабильностью MediaPlayer связаны с вендорами, которые могут нестандартно реализовать свои кодеки, яркий пример — Allwinner.
Из фреймворков для мультимедиа могу порекомендовать github.com/google/ExoPlayer. На последнем Google IO в секции про Android TV главный разработчик сего фреймворка про него рассказывал.
ExoPlayer внутри использует MediaCodec API.
Кстати, у MediaPlayerService в с++ части есть метод getOMX (пример как использовать).
И вы всегда можете его получить с 2.3.
Небольшое уточнение, в Android за декодирование отвечает OMX (OpenMAX IL, если быть точным). Stagefright это гугловый плеер, который реализован при помощи OMX. Помимо stagefright для RTSP и HLS используется NuPlayer.
Т.е. копать вам надо в сторону OMX. Но и не все производители снабжают свои устройства OMX плагинами. Яркий пример — Allwinner. У них свой плеер и свой медиа стек.
Можете посмотреть «простой» пример из ffmpeg. Там куча багов, работает не на всех устройствах (проблемы с цветом или некорректная инициализация декодера)
Затем можно заглянуть в код XBMC, VLC и в последний gstreamer (самый взрослый код из всех открытых проектов).
Или Вы про Allwinner интересуетесь?
это сам system.img, заменяете его на тот что лежит в папке system-images/android-15/x86/, создаете новый образ и карты работают.
Как видите, эта схема поддерживается на уровне самого sqlite. Никаких доп. запросов он не делает.
И мои пять копеек к orm for android: ActiveAndroid (Active record style SQLite persistence for Android). Это уже конечно более высокий уровень по сравнению с курсором, и подгрузка данных происходит тогда когда она нужна, НО в андроиде этот подход опять же не оправдан, т.к. здесь везде хотят курсор, и кто его знает как эти все ORM монстры «запоют» на каком-нибудь huawei ideos :). В отличии от Android, в iOS ActiveRecord подход оправдан, там хотя бы железо всегда адекватное.
Я имел ввиду один из способов работы с БД, а именно использование сторонней библиотеки в которой уже почти все есть =). Конечно, лучше наверно сразу использовать какой-нибудь ormlite, но все же.
А это не смотрели?
ну, там все просто… «читайте книги — источник знаний» (с) М. Горький
Читайте последний комментарий.
А что такое «приложение убежавшее из песочницы»?
Каких таких приложений? Malware?