А тем временем в Беларуси строится убийца Hyperloop. Автор идеи:
Тот же Илон Маск или, допустим, Hyperloop — сейчас они собрали 200 миллионов долларов. А что они сделали?… А посмотрите, что мы сделали за меньшие деньги!
<на правах рекламы :)>
Когда-то много-много лет назад и я делал что-то подобное. У приложения тоже сложная судьба со своими взлетами и падениями, с банами в Google Play и уходом в подполье. Правда в качестве источников треков используется не зайцев.нет, а vk.
</на правах рекламы :)>
Но в весьма ограниченном виде. Нельзя например использовать векторные картинки в drawableLeft и прочих drawable* для TextView, нельзя использовать для иконок системных нотификаций. Зато смело можно использовать в ImageView при помощи нового атрибута app:srcCompat.
Не совсем понял, в чем преимущества над уже хорошо зарекомендовавшими себя решениями (fresco, UIL, Picasso)? В минимализме или еще в чем-то? Хотелось бы услышать развернутое сравнение с конкурентами: наличие/отсутствие фич, перфоманс, размер и пр.
Полный код такого фрагмента тут
Он позволяет создавать как простые фрагменты-диалоги типа
new ConfirmDialogFragment.Builder(this)
.title(R.string.menu_logout_confirm_dialog_title)
.message(R.string.menu_logout_confirm_dialog_text)
.show();
… так и более сложные с передачей диалог-тега (для идентификации конкретного диалога в колбеке), установкой стиля, передачи дополнительных данных (cookie), которые будут доступны в колбеке.
new ConfirmDialogFragment.Builder(this)
.title(R.string.menu_logout_confirm_dialog_title)
.message(R.string.menu_logout_confirm_dialog_text)
.okButton(R.string.button_logout)
.dialogTag("confirmLogout")
.cookie("user", user)
.destructive()
.show();
Все это нормально переживает пересоздание активити.
А я комбинирую вариант имплементации кастомного интерфейса и вариант с использованием методов setTargetFragment и getTargetFragment. Выглядит это так: хост-фрагмент (вызывающий диалог) имплементирует интерфейс-колбек, далее в диалоге он устанавливается как target-фрагмент, при возврате результата getTargetFragment кастится к интерфейсу и дергается колбек. Плюсы такого подхода перед описываемым — отсутствие необходимости упаковывать-распаковывать результаты в intent, более очевидный и чистый код.
Обрезая качество мы выкидываем слова из песни и в итоге люди не владеют всей информацией.
Это большая ошибка!
Лучше просмотреть видео в качестве 480p вместо 720р, чем не посмотреть вовсе. Разве нет?
Сейчас ни у кого в городах нет на столько больших проблем с интернетом, что бы не посмотреть видео hd формата.
Ошибаетесь. Например на Украине до недавнего времени 3G вообще не был распостраненен, а на текущий момент один из ведущих операторов Киевстар обещает покрыть областные города только к 2016 году.
Да и вообще, разговор же не про необходимость таких технологий, как адаптивный стриминг. По-моему, кроме Вас никто не ставит под сомнение их необходимость. Разговор про то, что Вы голословно утверждаете, что «в нём собрано всё лучшее от Exoplayer, Vitamio и других». Можете сказать, что именно лучшее вы реализовали в своей либе кроме как кеши? Да и кеш работает кое-как. Глянул сэмпл из маркета. Там ведь не работает кеш при скроле в произвольную позицию! Т.е. для нормальной работы кеша нужно полностью просмотреть видео. Это сводит полезность практически к нулю.
«Большая сила порождает большую ответственность» (с): )
EventBus и им подобные решения — очень мощные, но опасные, т.к. уменьшают очевидность хода выполнения приложения.
То есть требуя от своих пользователей «толстого» интернет-канала, Вы способствуете прогрессу, а создавая новый протокол, позволяющий просматривать видео youtube на слабом интернет-канале, Google тормозит его?
Я рекомендую потому что провёл много тестов плееров. И дело не в том что другие плееры могут подходить хуже к прокси. Дело в скорости их работы и глючности. Я много общался с авторами плееров на гитхабе и даже в личных сообщениях. Они не планируют исправлять что-либо. Если это и будет, то через 1-2 года.
Когда я говорил о интересном библиотечном решении, я имел в виду ImortalPlayer, а когда говорил, что автор не рекомендует его использовать для других плейеров, имел в виду Ваши же слова «Easy to use with different other player, but! Not recommended». Что собственно и подтверждает мои первоначальные слова «Механизм кеширования привязан к конкретной реализации плейера.»
2.
Почему-то мне попадается только 1% библиотек с тестами. Возможно мы в разных областях работаем. Взять хотя бы приложение play.google.com/store/apps/details?id=com.desarrollodroide.repos&hl=ru найдите там с тестами проект))). Что-то нету.
В этом сборнике в основном UI библиотеки. Тесты для них не так критичны. У вас же библиотека неUIайная (опциональная по вашим же словам реализация TextureView-плейера поверх прокси не в счет). В ней много работы с сетью, сокетами, файлами. Это нуждается в тестах.
3.
Я пойму свой код через 5 лет, если надо. Достаточно быстро.
Завидую Вашему оптимизму.
Для этого статья. Читайте и понимайте.
Объяснить идею обычным привычным языком — легко, очевидно объяснить её кодом — нет.
Я думаю вы не до конца понимаете что это за модуль и вам действительно нужно сделать свой. Этот модуль слишком навороченный. Вам нужно попроще.
Я прекрасно понимаю, «что это за модуль». Просто я хочу донести как можно более обоснованно и деликатно, что реализация его далека от идеала.
Этот модуль слишком навороченный. Вам нужно попроще.
Навореченный? Нет. Избыточно сложный в реализации — да.
4.
Да хоть 140 пусть пустых будет! Какая разница, если они должны быть пустыми, значит так и будет. Или вы предлагаете ошибки пользователям отображать??)) Что с ними делать, если никак нельзя страховать ошибку?
Я ничего не предлагаю. Я просто говорю, что повсеместно глушить ошибки — это плохой «запах» кода. Читайте классиков программирования. Да и далеко не одних catch-ах проблема, это просто пример.
5.
Я же написал, что можно на лету хоть видео конвертировать. И ваши примочки, особенно DRM — для меня, как дьявол какой-то. Я категорически против любых DRM. Это всё от лукавого.
Что вообще вам надо??? Вы видели моё приложение Media Library?? Как там из пиринговых сетей воспроизводится видео хоть HD, хоть 4К формата прямо на телефоне. У меня скорость интернета на телефоне через 4g 15-30 м\бит… Этого достаточно для того что бы сказать, что все ваши видео примочки не нужны больше. Настало новое время. Достаточно просто http плеера.
Очевидно, что Google (создатели DASH), Microsoft (создатели SmoothStreaming) так не считают.
Напротив, я всё понял. Я хочу иметь возможность использовать интересное библиотечное решение для других плейеров, но автор библиотеки этого не рекомендует. Что мне остаётся, кроме как 1) допилить авторское решение 2) написать своё. Если сам автор пасует перед этой задачей, то, разумеется, лучше выбрать второй подход.
2.
На гитхабе большая часть библиотек без тестов и что теперь? Не использовать их?))
Я этого не говорил. Но без сомнения отдам предпочтение библиотеке с тестами. А иначе где доказательства того, что она работает корректно? Как вносить изменения в код без уверенности, что чего-то не поломал? И да, я стараюсь не использовать библиотеки без тестов. Не поленился просмотреть зависимости своего последнего проекта и обнаружил, что около 80% используемых библиотек имеют тесты. Отсутствие тестов в Вашей библиотеке — это бесспорный минус Вашей библиотеки, с этим бессмысленно спорить.
3.
Для меня этот код, как детский стих.
Поймёте ли Вы его через 2 года? Поймёт ли его другой программист? Ведь, как известно, 80% программист проводит в чтении своего или чужого кода и только 20% в написании.
Ничего там нет сложного, если понимать, что происходит.
Разумеется: ) Сложность-то как раз в том и заключается, чтобы понять: )
Да и чего вам надо? Статью написал, картинки сделал, код опубликовал. Вопросы есть? — задавайте! На русском языке даже отвечу))
Как я говорил выше, к статье-то как раз нету никаких вопросов: всё грамотно и интересно.
О чём ещё можно мечтать???
О прекрасном, чистом, очевидном коде, который не боязно вставить в прадакш проект: ).
И если код ещё выносить в сторонние процедуры, то будет только сложнее.
Есть тысяча и один способ повысить читаемость кода и, да, вынесение в метод — один из них.
4.
Где пустые catch блоки — значит так надо.
Сложно поверить, что в например в HttpGetProxy 18 пустых catch блоков из 23 — это норма. Если есть желание обсудить код, можно это сделать на гитхаб ;)
А вы лезете со своим уставом в чужой монастырь. Не надо так.
Разве в мире opensource это не поощряется?
5.
А класс плеера, я очень долго отлаживал.
Возможно всё-таки стоит использовать тесты? Тогда не придется «очень долго отлаживать».
В нём собрано всё лучшее от Exoplayer, Vitamio
Вы уверены в этом? Ваш плейер поддерживает DASH, SmoothStreaming, DRM, он супер расширяем? Ведь это несомненно самое лучшее, что есть в ExoPlayer.
1. Механизм кеширования привязан к конкретной реализации плейера. Что если я хочу использовать другой плейер, например ExoPlayer, или использовать механизм кеширования при стриминге аудио?
2. Я настороженно отношусь к коду библиотек без тестов.
3. Код местами объективно ну очень сложен. Чего только стоит метод из ~750 строк
4.… и не без огрехов: пустые catch блоки, смешение логики и представления, копипаст,…
5. Не проверял (и не смог понять из логики выполнения из-за п.3), нормально ли обрабатываются ситуации докачки видео, перехода в произвольную позицию во время стримминга, без которых кеш по сути теряет смысл.
Спасибо за интересную статью. Проблема не нова и готового решения я тоже не нашёл. Попытался было применить Вашу библиотеку, но отпугнули некоторые Ваши решения в коде. Потому сделал «свой блекджек» ) Но за идею спасибо.
Когда-то много-много лет назад и я делал что-то подобное. У приложения тоже сложная судьба со своими взлетами и падениями, с банами в Google Play и уходом в подполье. Правда в качестве источников треков используется не зайцев.нет, а vk.
</на правах рекламы :)>
drawableLeftи прочихdrawable*дляTextView, нельзя использовать для иконок системных нотификаций. Зато смело можно использовать вImageViewпри помощи нового атрибутаapp:srcCompat.Он позволяет создавать как простые фрагменты-диалоги типа
… так и более сложные с передачей диалог-тега (для идентификации конкретного диалога в колбеке), установкой стиля, передачи дополнительных данных (cookie), которые будут доступны в колбеке.
Все это нормально переживает пересоздание активити.
Ошибаетесь. Например на Украине до недавнего времени 3G вообще не был распостраненен, а на текущий момент один из ведущих операторов Киевстар обещает покрыть областные города только к 2016 году.
Да и вообще, разговор же не про необходимость таких технологий, как адаптивный стриминг. По-моему, кроме Вас никто не ставит под сомнение их необходимость. Разговор про то, что Вы голословно утверждаете, что «в нём собрано всё лучшее от Exoplayer, Vitamio и других». Можете сказать, что именно лучшее вы реализовали в своей либе кроме как кеши? Да и кеш работает кое-как. Глянул сэмпл из маркета. Там ведь не работает кеш при скроле в произвольную позицию! Т.е. для нормальной работы кеша нужно полностью просмотреть видео. Это сводит полезность практически к нулю.
EventBus и им подобные решения — очень мощные, но опасные, т.к. уменьшают очевидность хода выполнения приложения.
2. В этом сборнике в основном UI библиотеки. Тесты для них не так критичны. У вас же библиотека неUIайная (опциональная по вашим же словам реализация TextureView-плейера поверх прокси не в счет). В ней много работы с сетью, сокетами, файлами. Это нуждается в тестах.
3.Завидую Вашему оптимизму. Объяснить идею обычным привычным языком — легко, очевидно объяснить её кодом — нет. Я прекрасно понимаю, «что это за модуль». Просто я хочу донести как можно более обоснованно и деликатно, что реализация его далека от идеала. Навореченный? Нет. Избыточно сложный в реализации — да.
4. Я ничего не предлагаю. Я просто говорю, что повсеместно глушить ошибки — это плохой «запах» кода. Читайте классиков программирования. Да и далеко не одних catch-ах проблема, это просто пример.
5. Очевидно, что Google (создатели DASH), Microsoft (создатели SmoothStreaming) так не считают.
2. Я этого не говорил. Но без сомнения отдам предпочтение библиотеке с тестами. А иначе где доказательства того, что она работает корректно? Как вносить изменения в код без уверенности, что чего-то не поломал? И да, я стараюсь не использовать библиотеки без тестов. Не поленился просмотреть зависимости своего последнего проекта и обнаружил, что около 80% используемых библиотек имеют тесты. Отсутствие тестов в Вашей библиотеке — это бесспорный минус Вашей библиотеки, с этим бессмысленно спорить.
3. Поймёте ли Вы его через 2 года? Поймёт ли его другой программист? Ведь, как известно, 80% программист проводит в чтении своего или чужого кода и только 20% в написании. Разумеется: ) Сложность-то как раз в том и заключается, чтобы понять: ) Любой код кроме разве что самых тривиальных случаев можно написать превеликом множеством способов. Как я говорил выше, к статье-то как раз нету никаких вопросов: всё грамотно и интересно. О прекрасном, чистом, очевидном коде, который не боязно вставить в прадакш проект: ). Есть тысяча и один способ повысить читаемость кода и, да, вынесение в метод — один из них.
4. Сложно поверить, что в например в HttpGetProxy 18 пустых catch блоков из 23 — это норма. Если есть желание обсудить код, можно это сделать на гитхаб ;) Разве в мире opensource это не поощряется?
5. Возможно всё-таки стоит использовать тесты? Тогда не придется «очень долго отлаживать». Вы уверены в этом? Ваш плейер поддерживает DASH, SmoothStreaming, DRM, он супер расширяем? Ведь это несомненно самое лучшее, что есть в ExoPlayer.
2. Я настороженно отношусь к коду библиотек без тестов.
3. Код местами объективно ну очень сложен. Чего только стоит метод из ~750 строк
4.… и не без огрехов: пустые catch блоки, смешение логики и представления, копипаст,…
5. Не проверял (и не смог понять из логики выполнения из-за п.3), нормально ли обрабатываются ситуации докачки видео, перехода в произвольную позицию во время стримминга, без которых кеш по сути теряет смысл.