Pull to refresh
13
0
Владимир @vovkab

User

Send message
> я скорее о svg

Тут есть 3 способа:
1. экспортировать как есть, но получим размытые картинки, обычно на hdpi
2. экспортировать все размеры в png и руками подправить иконки для hdpi, tvdpi и тд.
3. создать отдельную копию svg для hdpi, подвинуть ее по сетке что бы избавится от блюра.

Мне больше нравится третий вариант, так как он легче и к тому же у нас уже все нарезается из svg автоматически. В итоге из mdpi svg мы получим png для mdpi(x1), xhdpi(x2), xxhdpi(x3). А из hdpi.svg -> hdpi.png.
> Не совсем понял этот момент, если у вас нарезаются из svg все нужные размеры, то зачем отдельный svg для hdpi?

Для того что бы избавиться от блюра. У вас даже пример есть с красным кружочком. С «фигурными» иконками, там особо смысла нет, так как мало что можно сделать, и там не так заметно.

> По поводу текста, в спецификациях мы отдаём расстояние до базовой линии, на не лэйбла. Иногда даём картинку с сеткой вроде вот такой:

Сетка это хорошо, но я не совсем понимаю как она помогает. Программисты сами все равно вычисляют коректный падинг?
Делаем в принципе все тоже самое, вот уже пару лет. (андроид)
Работаем со скетч фалом напрямую, оттуда сохраняем svg. Gradle плагин (https://github.com/avianey/androidsvgdrawable-plugin) нам нарезает все нужные размеры. Если у иконки есть ровные линии, то делается отдельный svg файл для hdpi, если сильно заметно.

Мне интересно что вы делаете с редлайнами для текста, например, то что показано на картинке «Пример работы скрипта Size Marks», не будет работать, так как не учитываются падинги для шрифтов. В примерe падинг сверху уже будет не 60, а 54, в добавок судя по картинке оба текстовых поля пересекаются друг с другом. Не знаю как в ios, в андроиде такого быть не должно :)
searchsoa.techtarget.com/definition/REST

REST (REpresentational State Transfer) is an architectural style, and an approach to communications that is often used in the development of Web services. The use of REST is often preferred over the more heavyweight SOAP (Simple Object Access Protocol) style because REST does not leverage as much bandwidth, which makes it a better fit for use over the Internet. The SOAP approach requires writing or using a provided server program (to serve data) and a client program (to request data).
Тоже самое. Пока сидели на гитхабе не было даже желания что то менять. Переехали на стэш сразу всплыло куча мелких недочетов:
— интерфейс какой то большой
— размер шрифтов не сбалансированный, где то большой где то мальнький
— не актуальные комиты не сворачивается
— нет дифа простыней
— в пр даже поиска/сортировки нет
— выделение бранча по дабл клику не работает в пр, а по тройному выделяется пол экрана
— в настройках не возможно выделить урл репозитария (да я знаю что можно из меню клонировать, но там он пихает имя юзера, а оно мне не надо)

И это я только вечер с ним провёл :)
V3.5.0
Он есть на локскрине, правда все равно надо 1 свайп и 2 клика :)

Дергаем шторку -> клик по текущему пользователю -> выбираем нового.
Ну как то совсем тяжко и уныло.

1. Под андроид полно тест фрэймворков, начиная от стандартных, Android Test (Espresso), UI Automator, Unit Test, заканчивая Robolectric, Appium и тд. На худой конец можно использовать, adb shell sendevents…
2. Зачем ездить по городу, когда есть Mock Locations? (http://developer.android.com/training/location/location-testing.html)
3. Зачем возьня с qr-кодами, когда можно использовать что то типа Hockeyapp, на худой конец накидать свой тест апп.
4. Почему нет подключенной краш статистики, сидите и ждете пользователей, когда напишут вам письмо? Если пользователь решит вам что то писать, -1 вам в гугл плэй обеспечен.
5. Почему ничего не сказано про поэтапное внедрение на Google Play? Ах да, зачем, смысла в же нет, у вас же нет краш статистики, в ней же ничего не понятно.

Лайфхак — займитесь автоматизированным тестированием.
Складывается впечатление, что ios разработчики волнуются за андроид фрагментацию больше, чем сами адроид разработчики :)
Видимо вот для таких вот случаев. Еще и бинарей туда напихают для терабайтности :)
Может мы не поняли друг друга. Но, то что новая фича — новая ветка, это даже не стоит упоминать, это само собой разумеющееся.
Выше, если я правильно понял, советуют иметь 2 ветки дополнительных ветки на каждую фичу, и что то куда то переносить. Вот я и пишу, что ничего переносить не нужно, фича ветка чинится с помощью ребэйза.
не нужно лишних веток, для этого всего есть git rebase
Эти куски нужно потом еще найти что бы выдергнуть и слепить комит из них, в общем проблемы на пустом месте.
Имхо проще и лучше всегда использовать комиты с нормальным описанием.

1. Если это рабочая репа, то всегда будет видна история, легко найти комит который что то ломает, так же легко перенести отдельные комиты в другие ветки, мержить намного легче, в общем все лучше :)
2. Если от вас требуется, как при отправке в герит, «патч файл», дублируем ветку, сливаем все комиты в один и отправляем. Что то надо доработать? У вас всегда есть исходная ветка, легко мержимся/ребэйзимся, и далее все заново.
Видите, за то теперь есть причина для самосовершенствования :)
Тут обсуждают даже не то что, что то залили в мастер, а вообще в нужности системы контроля версии, и это пишут программисты, лол :)

Сразу определимся что, наживую в мастер ни кто ничего не льет, он только для релизов, все фичи по отдельным веткам, и потом мержатся с --no-ff в дев. И далее по git flow.

По поводу одного комита, тут сложно согласиться что он легче, чем пачка, особенно при мерже. Только если это не микрофича.
Когда есть комиты и нормально расписаны что они делают, и делают что то одно кокретное, их очень легко мержить или ребэйзить, так как не нужно вникать в логику всей фичи, а только конкретного комита. А когда у вас огромный комит, с 100+ изменений, конфликтов может, как будто меньше, но они на самом деле заметно больше, нужно дольше вникать что и как должно работать. Так же с большим комитом, нет возможности что то отменить позже. Так что я бы не стал экономить на комитах и описании ;)
Все зависит от вашей схемы ветвления.
Если вы по сути один, то по этому и лепите все в мастере. Если будете не один тогда прийдут все эти ветки.
Вот тут хорошее описание про один из способов использования гит веток: nvie.com/posts/a-successful-git-branching-model/
Интересное решение. Если правильно понял, то вы что бы зафиксировать новое изменение, вы создаете новую ветку? Если это так, то можете пояснить, в чем отличие от нового комита в одной ветке и слиянием их всех после? Или же вы создаюете ветку для фичи с пустым комитом и потом все время добавляете в него?
Вы не путаете комиты с пушем в удаленный репозиторий? Думать над именем комита можно и позже и комитить сколько влезит пока все не сделаешь. А уже в конце перед пушем все почистить, написать сообщения для комитов или вообще все комиты заново нарезать.
У вас ответ как у менеджера или клиента. Какие нафиг рефакторинги, какой код, какая еще спецификация мне просто нужна работающая программа.

Автомобили. Это если вы спроектировали и сделали, скажем, дверь для машины, принесли, а уже все поменялось, и вас просят исправить все крепления да и вообще всю форму двери что бы она подходила к новой машине.

А если по делу, пример что вы привели вполне класический, если есть трудности с ним, может есть смысл почитать документацию, пройти туториалы, на курсы там сходить что ли? Как вы себе представляете что бы система контроля версий, за вас исправила логику в коде?
А как у этой штуки на счет производительности, тестируемости и поддерживаемости?
минусующим, грэдл и новая сборка появилась не вчера, а уже достаточно давно. Потратив 10-20 минут в неделю на чтение и тесты помогли бы избежать проблем выше.
Так же копипаста 150+ строк конфига, в котором половина не понятно всегда плохая идея.
А теперь люди перескакивающие с эклипса просто в ужасе, сколько им теперь нужно учить и разбираться, а ведь можно было бы это все избежать, времени было и есть достаточно.

Information

Rating
Does not participate
Location
California, США
Date of birth
Registered
Activity