Pull to refresh
20
0
Vitaly Gashock @gshock

User

Ну что значит проект не можно будет завершить? На любом языке можно написать тонны макарон и паровозов. Чтобы не было длинных паровозов нужно выделять код в отдельные функции/виджеты. И в Dart-е никто же не отменял нормальных практик написания кода.
Немного странно видеть вложенный в ConstraintLayout CardView, который для размещения вложенных компонентов использует RelativeLayout
Вроде даже встроенная в Android Studio заготовка проекта с боковым меню «умеет» вложить внешний лайаут в выдвижное меню. Не понял вообще проблематики из статьи
Статья ради картинок получилась, в 3-м тысячилетии моветон настраивать Хибернейт через XML, И да, комрады правы, пора абстрагироваться от хибернейта в пользу того же Spring Data JPA/JPA3
Может, для начала, стоит научиться «ходить в сеть» без Retrofit-а?
Может глупый вопрос спрошу: а вообще-то на JavaFx кто-то сейчас пишет в промышленных масштабах?
А мне вот в Dagger 2 не понравилось то, что setupComponents() нужно реализовывать в каждой activity/fragment. Нельзя просто взять и вынести этот код в базовый класс activity/fragment. Он просто не будет работать и инъектить зависимости
При наличии которого большинство разработчиков так и будут продолжать колбасить по-старому
Вообще-то это не статья, а набор переведенных слайдов с комментариями с вчерашнего шоу Android Design In Action
Интересующимся советую посмотреть предыдущие выпуски
SlidingMenu — это хорошо, но лучше использовать рекомендованный официально паттерн Navigation Drawer. По личному опыту переезда в двух проектах со SlidingMenu на Navigation Drawer скажу, что последний работает лучше и внедрять его намного проще
перейти-то на сам язык несложно, а вот почитать ui-гайдлайны платформы и рекомендации по построению ui все-таки ой как нужно
Эти пикеры рассчитаны на 4.x Android
Хотя что-то мне подсказывает, что при желании их можно портануть и на более низкие версии АПИ
Вообще-то поддерживать разные ориентации экранов в приложении является даже больше, чем правило хорошего тона.
Возможно, у кого-то этото впорос стоит остро, но у меня не было задачи менять структуру лейаута при повротах. Поэтому все корректно масштабировалось само. А где лейаут у меня строился в зависимости от размера экарна я и так его просчитывал в ручную.

Комрад имел ввиду не столько изменение UI, сколько обработку сохранения и восстановления текущего состояния активити.
2. Не верю

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

В случае, когда нужно организовать синхронное общение с сетью (например, общение с REST API) то IntentService подойдет нормально.
А вот если нужно делать параллельные асинхронные запросы — то да, согласен с вами
Вы правы, не хендлятся. В демо это осознано упрощено дабы показать как работает связка IntentService+ResultReceiver. Понятно, что в реальной жизни нужно обрабатывать перевороты экрана.
Именно так, придется писать под разные платформы. Но зато это будет нейтив-приложение со всеми вытекающими. А для почты пользоваться мобильным сайтом неудобно ИМХО. Я бы не стал пользоваться
Перейдите тогда на айФон
*имел ввиду Fly-In App Menu

Information

Rating
Does not participate
Location
Одесса, Одесская обл., Украина
Date of birth
Registered
Activity