Как стать автором
Обновить
9
0
Денис @KamiSempai

Android/iOS Разработчик

Отправить сообщение
Если getActivit() возвращает null, значит вы либо не вовремя к ней обращаетесь, либо уже поздно.

На счет того, что «использование обычной view выходит проще» не соглашусь. В моем примере все сделано в одном xml у вас же еще куча дополнительных классов.

Аргумент про «чуть меньше ресурсов» тоже весьма спорный. Если уж так хочется экономить ресурсы, советую начать использовать FrameLayout вместо RelativeLayout. Как раз сэкономит ресурсы, что-бы для фрагментов хватило.
Похоже на велосипед. Не вижу здесь ни какой проблемы. Почему бы просто не использовать фрагменты?
Пример xml разметки
<android.support.v4.widget.DrawerLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/drawer_layout"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <FrameLayout
        android:id="@+id/content_frame"
        android:layout_width="match_parent"
        android:layout_height="match_parent"/>
    
    <fragment
        android:id="@+id/left_drawer"
        android:layout_width="300dp"
        android:layout_height="match_parent"
        android:layout_gravity="start"
        android:name="com.package.SlidingMenuFragment"/>

</android.support.v4.widget.DrawerLayout>
Тут не соглашусь. есть физический ограничитель. такой нож не поместится в руке обычного человека.
В качестве аргумента приведу отрывок из книги Генриха Альтшулера «Найти идею. Введение в ТРИЗ – теорию решения изобретательских задач»
Задача 1.3
В книге В. Губарева «Космическая трилогия» приведены слова одного из конструкторов спускаемого аппарата станции «Венера-8»: «Каждый грамм веса и кубический сантиметр пространства внутри “шарика” использованы рационально. Могу заверить, что вам не удалось бы “впихнуть” туда даже спичечный коробок. Такого плотного монтажа я не встречал ни в одной конструкции»[5 — Губарев В. Космическая трилогия. – М.: Молодая гвардия, 1973. – С. 203.].
Предположим, возникла необходимость «впихнуть» в «шарик» не спичечный коробок, а прибор весом в 6 кг. Как вы думаете, удалось бы «впихнуть» прибор или нет? Если нет – почему? Если да – каким образом?



Обратимся к статье научного обозревателя «Правды» В. Губарева «100 минут среди тайн». Речь идет о станции «Венера-12».

«Был в спускаемом аппарате центровочный груз. Да и как обойтись без него, если необходимо, чтобы “шарик” занимал строго определенное положение в пространстве?»[7 — Правда. – 1978, 22 дек.]

Идеальный центровочный груз – когда груза нет, а функции его по совместительству выполняет какой-то другой объект. В виде общего правила это сформулировано еще в 1956 г. в первой же печатной работе по ТРИЗ: «…на данную систему дополнительно переносятся функции другой системы, за счет устранения которой появляется возможность увеличить вес первой системы» (Альтшуллер Г.С., Шапиро Р.Б. Психология изобретательского творчества // Вопросы психологии, № 6, 1956. – С. 37–39). В статье В. Губарева рассказывалось: однажды к конструкторам пришел ученый из Института геохимии и аналитической химии и попросил разместить на «Венере-12» еще один прибор весом в 6 кг. «Взрыв смеха. Это уже слишком – предлагать такое… О каком приборе может идти речь, если аппарат уже сделан и каждый грамм веса рассчитан?» Ученый настаивал: надо разместить прибор. Идея пришла неожиданно: снять центровочный груз. Прибор выполнял свои функции и одновременно играл роль груза…

(Теперь самое время вернуться к задаче 1.3. Сформулирована она вполне конкретно: если конструктор сказал, что свободного места нет даже для спичечного коробка, значит – свободного места нет. В условиях не упоминается, что в «шарике» был балласт – центровочный груз. Но для решения задачи в общем виде это не имеет значения. Идеальный прибор – когда прибора нет, а функции его выполняются. В этом смысле нет предела плотности монтажа: теоретически в один и тот же объем можно «впихнуть» неограниченное количество приборов…)

Использование прибора в качестве конструктивного элемента (например, центровочного груза) – это прием, азбучный для ТРИЗ. Если этот прием оказался «неожиданным», наверняка он не был применен в более тонких и не столь очевидных случаях. К тому же это всего-навсего один прием – капля в океане смелых и неожиданных идей современной теории решения изобретательских задач.

Я говорю про несоответствие таких скрещиваний принятым нормам в обществе. в моем обществе такая форма одежда неприемлема.
Какая разница какие нормы приняты в обществе? Если вы считаете себя изобретателем, отчасти вы и задаете эти самые нормы. За примерами далеко ходить не нужно, над Стивом Джобсом смеялись когда он продвигал идею персонального компьютера. Общество тогда и представить не могло такого.
В случае с ножом все до банальности просто – он не помещается в руку, а значит смысла в нем нет.
То что у вас это не получилось не значит, что подобное невозможно. Возможно вы просто не компетентны в данном вопросе, либо нужны знания из области в которой вы не являетесь специалистом.

Смысла в пересечении Windows и iOs, Mailchimp и MailGun, Ubera и Gett попросту нет. У них одинаковые потребительские характеристики. Ничего принципиально нового от такого соития мы не получим. В лучшем случае что-то точно такое же.
Принципиально нового, например спиннер, из этого может и не получится, но если учесть все их недостатки и достоинства, на выходе может получиться достаточно востребованный продукт.

«нельзя скрещивать атомные ядра одних частиц с другими ядрами или элементарными частицами. Последствием взаимодействия может стать деление ядра и испускание новых элементарных частиц. Кинетическая энергия вновь образованных частиц может быть гораздо выше первоначальной»
Может подобный результат и является целью скрещивания? Тогда получается можно. И что значит нельзя носить носки со шлепками? Скажите это японцам. У них для этого даже специальные носки есть, Таби называются.

PS: У вас первая ссылка ведет на какой-то лохотрон, а не на видео.
Каждый хороший программист проходит через «Синдром патернизации всего и вся». Даже если сейчас он их не знает, рано или поздно он все равно заинтересуется паттернами. Так что чем раньше он этим переболеет тем лучше.
«Зачем вообще специально учить паттерны?»
Знать названия паттернов нужно как минимум для общения с коллегами. Причем все знать не обязательно, достаточно помнить самые часто используемые. Их можно по пальцам пересчитать.

«Зачем мне знать название для решения, которое я сам спокойно придумал и прекрасно осведомлен о его плюсах и минусах?»
Можете ли вы быть на 100% уверенным, что ваше решение не будет антипаттерном? Сколько времени вы потратите на поиск собственного решения?

Вообще такое мнение, как ваше, говорит лишь об отсутствии стремления к саморазвитию. Такие люди довольствуются знаниями полученными в процессе работы ну и изредка из прочитанных статей. Вы вот например когда последний раз книгу по своей профессии читали и какая это была книга?
Это не совсем так. Бан можно получить только за поощрение положительных оценок. Автор же предлагает поощрять за сам факт того, что пользователь поставил оценку, даже если она была негативной.
Пруф: Центр правил для разработчиков: Рейтинги, отзывы и количество установок
Тут я с вами частично согласен. Но данный подход применим к программистам уровня Senior+ или Guru. И если уж вы дали такое задание, вы должны четко понимать для чего вам это нужно. Так же неплохо было бы дать это понять и соискателю.
В большинстве же случаев, в этом нет необходимости. Иной раз доходит до смешного. Одному моему другу, Java разработчику, дали бумажное задание на Паскале! Что еще более забавно, через месяц, когда он уже нашел себе работу, ему позвонили и сказали, что он прошел на второй тур.
На самом деле, любой вопрос который вы задаете могли спросить уже вчера. Тут просто нужно более грамотно подходить к процессу, и если задается вопрос про патерны/технологии/утилиты то стоит в догонку распросить и про недавние случаи их применения.
Чуть не забыл. На любом собеседовании обязательно нужно спросить про паттерны. И попросить реализовать синглтон. Наверное, нужно было поставить это первым пунктом.
Чего плохого в том, что бы спросить про паттерны? На моей практике были случаи когда кандидат просил зарплату в 100к рублей, при этом не мог назвать ни одного паттерна, кроме синглтона.
Помимо видео уроков StartAndroid есть еще и сайт http://startandroid.ru с уроками в текстовом виде.
Как по мне, так уроки на сайте StartAndroid будут по лучше чем блог Александра Климова. По крайней мере так было когда я только начинал изучать Android.
Сейчас пересмотрел код еще раз и заметил, что при наследовании от BaseViewModel вы не определяете новый CREATOR. В таком случае, получается, у вас из Parselable должен восстановиться объект BaseViewModel а не ViewModel. Да и не видно работы с Parcel в самой ViewModel. Это так задумано или ошибка по недосмотру?
Если что, в EditText текст сохраняется и без чьей либо помощи. Это уже по умолчанию зашито в самой Activity.
Интересная проблема выискивается после того, как мы откроем другую активити и вернемся назад, а все введенные данные останутся, ибо при открытии и возврате не вызывается метод onCreate.
Не вижу ни какой проблемы. При возвращении в предыдущую Activity она, в большинстве случаев, должна сохранять свое состояние.
setRetainInstance(true) не избавляет вас от обязанности сохранять состояние, так как на не помогает в случаях когда Activity была уничтожена и затем восстановлена. Я вообще советую никогда эту опцию не использовать. Разве только в редких случаях, когда восстановление View крайне дорогая операция.
Могу предложить свое решение: LocoLaser: переводим приложения в Google Sheets
Работает с Android и iOS. Ресурсы находятся в гугл таблицах. Умеет генерировать Swift и Obj-C классы. Есть плагин для Gradle.
Если какой-то компонент нужен вам в коде, вы делаете на него аутлет. И это нормально.
В статье описана ситуация с надписями которые не меняются в процессе работы программы. Тянуть ссылки на них в код, только чтобы поставить текст, мне кажется немного топорным решением.
Возможно вам стоит взглянуть вот на этот подход: Удобная локализация iOS приложений в Interface Builder
Это та самая «первая» статья из двух за месяц. В ней я рассказал как можно избавится от аутлетов.
Как по мне, так отдавать переводчикам JSON — неблагодарное дело. Обязательно что-то поломают. Код-ревью в этом случае выглядит как костыль.
Также, замечу, тема локализации Storyboard не раскрыта. Или вы готовите еще одну статью?
Работа со строками в iOS сделана таким образом, что невозможно иметь общую строковую базу на несколько платформ и не городить при этом велосипедов. Очевидно, вы разрабатываете только под iOS и не сталкивались с этой проблемой.

PS: хотел третью статью написать. Но видимо придется повременить. :)

Информация

В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Дата рождения
Зарегистрирован
Активность