Открыть список
Как стать автором
Обновить

Комментарии 27

Сложно понять, что сподвигло архитекторов на подобное решение

Я тоже над этим размышлял, думаю это по большей части связано с 2 проблемами:
1) Что делать, если Activity имеет разные ресурсы для портрета и лендскейпа. С одной стороны, наверно можно было бы сделать какое-то отдельное АПИ, чтобы обрабатывать эти случаи. Но тогда жизненный цикл отличался бы для Activity с разными ресурсами, что довольно неудобно.
2) Есть много других ситуаций, когда Activity меняет конфигурацию и тоже пересоздается. Но они менее очевидные и частые, чем простой поворот экрана. Возможно архитекторы хотели таким образом зафорсить обработку всех подобных случаев, чтобы разработчики на оставляли баги.

Может есть еще какие-то более глубокие причины, систему очень давно начали писать.

Ну а в целом архитектура говно, да.
Но перечисленные проблемы очень базовые и все уже как-то научились с этим жить, используя либы, наработки умных дядек и правильные подходы к написанию кода.
Ну а в целом архитектура говно, да.

А можно в двух словах почему именно говно? Что бы вы сделали по-другому?
В двух словах — вряд ли, это все-таки SDK.

Плохо практически все, начиная с View. Сырцами View, ViewGroup и ViewRootImpl можно детей пугать, об этом говорят даже ребята из гугла, которые работают над графическим фреймворком.
View знает обо всем на свете, имеет много лишнего API, которое должно быть у сабклассов, а у нее.

Были хреновые ListView, ScrollView. Решили сделать хорошо в RecyclerView, в итоге урезали некоторые фичи, нужно все так же писать тонну кода, чтобы сделать простейший список, а LayoutManager по сложности реализации может потягаться с полностью кастомной вьюхой.
Про NestedScrollView вообще молчу, в нем до сих пор столько нелепых багов, что использовать в более-менее сложном сетапе просто невозможно.
FitsSystemWindows, Window Insets, CoordinatorLayout с его Behavior, для всего приходится писать кучу костылей, чтобы оно хоть как-то вменяемо работало.
Chris Banes, главный по суппорт либе, целые гайды по костылям пишет.

Куча глобальных состояний и мемори ликов связанных с этим, начиная с абсолютно базовых вещей типа InputMethodManager.

Нет нормального API для асинхронщины. Но это по крайней мере решается библиотеками.

Bluetooth — тихий ужас.

Фрагменты — неудобное API, нет чего-то типа transaction listener, сложный lifecycle, особенно для вложенных фрагментов. А для фрагментов добавленных в XML он еще другой. Краши на коммитах после saveInstanceState, баги и лаги в анимациях перехода, рандомные краши в местах типа onCreateOptionsMenu.

Различные проблемы с клавиатурой и фокусом.

Architecture Components сейчас пытаются решить некоторые проблемы с архитектурой для отдельных скринов, сложностью жизненного цикла компонентов нетестируемым кодом.
Но все равно как-то местами криво получается. ViewModel хранится, используя retained фрагменты, LiveData имеет несколько дизайн просчетов…

Вообще многовато проблем для комментария, но статью я не сильно хочу писать, т.к. в ней нет особого смысла, просто будет нытье какое-то :)
Гм, весьма спорная статья с точки зрения андроид разработчика. Можно много чего написать, пройдусь только по некоторым моментам.

Сложно понять, что сподвигло архитекторов на подобное решение.
Все просто. Приложение может иметь разную разметку экрана (layout) в портретной и ландшафтной ориентации. Чтобы ее загрузить, старая активити убивается, а новая создается, так как набор view на экране может изрядно отличаться. А тот самый флаг как раз таки говорит о том, что разработчик сам знает, что делает. Т.е. если я знаю, что разметка будет та же самая, то могу выставить этот флаг и все останется так как есть.

Android предоставляет своим пользователям аж целых четыре механизма асинхронной работы: AsyncTask, Service, IntentService, Thread.
Не совсем так. Service сам по себе никак не связан с асинхронной работой, так как использует основной поток. IntentService является наследником Service, и имеет внутри Handler для обработки очереди событий в отдельном потоке. AsyncTask это просто обертка над работой с потоками. Так же не упомянуты Handler и Loaders. А если отступить от собственно андроида, то есть еще RxJava и Kotlin coroutines.

Получается, при создании Activity все равно нужно отслеживать “холодный старт” и проводить инициализацию вручную. Не говоря уже о том, что при перезапуске не восстанавливаются никакие Thread и AsyncTask.
Не вижу особых отличий от десктопа. Да, на десктопе обычно система не выносит приложения, но если уж оно умерло, то умерло, вместе со всеми потоками и данными в памяти.

Оказалось, что стандартный класс HashMap (который мы используем для получения объекта Java по его ID) в нашем случае неэффективен
Даже не могу представить, что нужно делать с HashMap, чтобы задолбать сборщик мусора…

Если вы хотите вставить в ваше приложение предпросмотр документов, вынуждены разочаровать: в Android нет встроенного компонента, который умеет показывать файлы Word, Excel, Powerpoint. Не говоря уже об архивах ZIP или документах PDF.
А где же он есть-то? В Windows? В Linux? Думаю в большинстве ОС эти функции делегированы сторонним приложениям. Андроид тут ничем не выделяется.
Андроид тут ничем не выделяется.
Как раз и выделился.

В macOS/iOS это всё есть.

Насколько я понимаю (а яблочных устройств у меня нет), этим занимается отдельное приложение, пусть и поставляемое с системой, но не встроенный компонент системы, о котором речь в статье.

А explorer.exe в windows — компонент или отдельное приложение поставляемое с системой?

Не силён в разработке под iOS, но немного погуглив вижу, что везде эти форматы отображаются через загрузку в UIWebView, это всё же не то же самое, что поддержка форматов на уровне SDK. Так и в андроиде можно сделать, загрузив нужный файл в WebView.
Если я не ошибаюсь, то macOS из коробки умеет только docx из офисных форматов. В iOS по-моему нет поддержки из коробки. В Android при желании можно много что добавить. И судя по тому, что большинство телефонов на Android доброго слова не стоит лучше таки что бы из коробки была поддержка не всего.

Но вот что меня по-настоящему смутило, так это то, что в Android нет поддержки ZIP. Как ее может не быть если jar это и есть zip.
Но вот что меня по-настоящему смутило, так это то, что в Android нет поддержки ZIP.
Так она есть.

1) вы комменты читали? :)


2) added in API level 1
ZipInputStream

Спасибо за ваш комментарий.

Вы пишете, что механизмов асинхронной работы еще больше. Это делает восприятие еще более сложным. Loader, кстати, будет deprecated, начиная со следующей версии API (28). Непонятно, почему AsyncTask до сих пор не deprecated, ведь он явно входит в противоречие с идеей пересоздания всех компонентов интерфейса при повороте. Любая ссылка, запомненная в объекте AsyncTask, будет нерабочей после окончания асинхронной задачи, если пользователь повернул экран во время ее выполнения.

Понятно, что архитекторы Android каждый свой выбор на чем-то основывали. И документация, конечно, опишет, какие компоненты и как использовать, чтобы получить требуемое вам поведение. Мы в большей степени акцентируем внимание на том, что некоторые архитектурные решения Android сомнительны, и в других ОС сделано по другому и в чем-то проще.

В хорошей архитектуре сама структура кода API подсказывает разработчикам как использовать платформу, а документация лишь дополняет ее. В Android же доверять интуиции не стоит, нужно всегда читать документацию. Например, идея, что Service обрабатывает события в том же потоке, а наследник от него IntentService создает отдельный поток, совершенно контринтуитивна.

Про «холодный старт» — в том-то и дело, что Android претендует на то, что в отличие от десктопа, ваше приложение, если написано правильно, вообще не заметит, как его выкидывали из памяти и потом рестартовали. А на самом деле технология не срабатывает, как только приложению нужна инициализация с подогреванием кешей.

Что касается просмотра файлов — в iOS аналог WebView приемлемо показывает документы Word/Excel/PDF. В Excel-документе можно даже переключаться между листами. В Android это не так.
Loader, кстати, будет deprecated, начиная со следующей версии API (28)

Вы неправильно читаете javadoc, ибо:
This class was deprecated in API level 28.
Use the Support Library CursorLoader
Я читаю документацию здесь:

https://developer.android.com/guide/components/loaders
Loaders have been deprecated as of Android P (API 28). The recommended option for dealing with loading data while handling the Activity and Fragment lifecycles is to use a combination of ViewModels and LiveData.

Можно, конечно, продолжать использовать через SupportLibrary. Но поставщик платформы явно рекомендует использовать другие механизмы. Опыт подсказывает, что если не следовать таким рекомендациям, то поведение приложения с каждой новой версией API будет становиться менее предсказуемым.

На самом деле этой весной много классов пометили как deprecated, но только потому, что версию support library можно обновить независимо от операционной системы, которого на многих устройствах не бывает в принципе.
И эти deprecated говорят только о необходимости обновить импорты, но в случае с Loader вы правы.

Если вы хотите вставить в ваше приложение предпросмотр документов, вынуждены разочаровать: в Android нет встроенного компонента, который умеет показывать файлы Word, Excel, Powerpoint. Не говоря уже об архивах ZIP или документах PDF.
А где же он есть-то? В Windows?

В Windows, zip-файл открывается как папка и можно с ним делать что угодно, в Линуксе gzip,bzip и прочие также присутствуют
Ну насчёт zip-архивов — в android есть классы для работы с ними, особых проблем с этим нет. А касательно стандартного компонента для отображения doc/docx/ppt/xls/etc — конечно, такого нет, да и незачем пихать в SDK компоненты для поддержки различных проприетарных форматов на все случаи жизни.

Это ISO форматы. С таким же успехом можно и jpeg/png из коробки не держать.

doc, ppt и xls вроде как совсем не ISO.
docx — вроде OpenXML, который ISO, но по слухам не всегда следует заявленному стандарту.

А патенты на MP3 истекли в 2017, но это не мешало андроиду их проигрывать из коробки.
А h.264 до сих пор поддерживает.
А по слухам Android лучше iOS.

Для того, кто не пишет под андроид годами (не набил еще всех шишек, а может уже и привык), впечатления от АПИ будут скорее всего плохими, объективно оно далеко от совершенства и удобства и дело тут не в джаве.

Тем более уже есть неплохой ответ на Swift, «Kotlin»!
С точки зрения андроид-разработчика есть очень много спорных моментов.
Например вот:
некоторые сценарии просто невозможно реализовать, например, ленту изображений

а как как же RecyclerView? Он как раз для такого и создавался.

Про активити уже ответили выше, не буду повторяться :)
Перед нами стояла задача показать в одной галерее файлы разных типов: и картинки, и видео, и документы. Проблема не в RecycleView, а в компоненте WebView, который не умеет показывать офисные файлы.
А вы свое приложение под iOS делали?
Если да, то можете такую же статью про iOS глазами Android разработчика написать?
У нас есть хорошее приложение под iOS. Первая версия вышла, если не изменяет память под iOS 3 или 4. Постараемся со временем поделиться опытом. Но основная наша работа — код писать, поэтому сроков не обещаем.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.