iOS vs Android - у Apple развяжется пупок?

[Dmitry67]

А я не так понял - Infuse это S1 ? ok.

Ну у него побольше экран, а нутро совместимо - у меня при загрузке говорит "Samsung Galaxy S 1"

[АццкоМото]

Вот думаю сразу перепрошивать с xda-developers или еще помучиться?

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

[dotcom]

Следит за твоими глазами. Параноя просто. Втыкаю его в USB копировать музыку в плеер. Ни-фи-га. Какие то две дуракция опции яблочного стиля. Ну разумеется в гугл. Читаю: надо ставить USB Mass Storage Enabler!!! Который еще требует root!!! Ну разумеется рут у меня был, но каково!!! Они что вообще?????????

Рут не нужен. Точнее, он нужен, если есть желание вернуть взад USB Mass Storage из коробки. Для десктопов есть драйверы и утилиты, которые монтируют MTP. Для Виндузы не знаю, что ставить, а для Мака есть Alt Mounter, ну или родным Android File Transfer пользоваться, который, похоже, студент какой-то на гугловой летней практике написал. Как уже писал, по-моему даже в этом топике, убийство USB Mass Storage - это не прихоть Самсунга или Гугла, а evil doing from music labels.

[Интеррапт]

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

Что значит, что-то не то пишу? Нужен доступ к адресной книге, к возможности отправки SMS с ссылкой, локации и т.п (всякие фейсбуки app request и твиттеры - это само собой). Только нужно это не в момент инсталляции продукта, когда юзер совершенно не понимает, какого хрена крестикам-ноликам нужно читать его адресную книгу, а в момент, когда юзер в крестиках-ноликах сам нажимает кнопку Share with Friends и поэтому его абсолютно не напугает, что в ответ операционка его попросит подтвердить, что мол сейчас произойдет доступ к адресной книге. А если юзеру никогда в голову не взбредет нажать Share, то и пермишенны на чтение адресной книги спрашивать не нужно. Это гораздо правильней подход. iOS этот подход обеспечивает, Андроид - нет.

Кстати, с новым Андроидом (4.3) похоже, что Гугл озаботились таки пермишеннами
http://gigaom.com/2013/07/26/how-androi ... by-design/

Сама функциональность пока скрыта (хоть и есть приложение, которое выкатывает это наружу https://play.google.com/store/apps/deta ... pplauncher). Но если Гугл это сделает public, то любопытно, насколько сильно нагрузка на девелоперов увеличится, учитывая, что нужно быть готовым к тому, что юзер может отрубить в любой момент любой пермишен в приложении. А вообще Гуглу нужно сделать концепцию разного уровня пермишенов. Ну типа essential, мол без которых прога жить не сможет и которые неотключаемые. И non-essential, которые можно отрубить в любой момент.

[Ljolja]

насколько сильно нагрузка на девелоперов увеличится, учитывая, что нужно быть готовым к тому, что юзер может отрубить в любой момент любой пермишен в приложении.

на 0.0001%

А вообще Гуглу нужно сделать концепцию разного уровня пермишенов. Ну типа essential, мол без которых прога жить не сможет и которые неотключаемые. И non-essential, которые можно отрубить в любой момент.

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

[Интеррапт]

на 0.0001%

А как ты посчитала? Например, у тебя есть код, который использует вибратор. Прописан пермишен android.permission.VIBRATE. А юзер его отключил. Т.е. теперь вызов
Vibrator v = (Vibrator) getSystemService(Context.VIBRATOR_SERVICE);
будет крешать программу с exception. Аналогично с сетью, файлами и еще десятком других возможностей. Сотни разных функций могут зависеть от десятков разных пермишинов.

Как минимум тебе нужно пройтись по всему своему коду (в тысячи и десятки тысяч строк) и прикинуть, какая строчка кода может вызвать exception (а это unchecked exception, т.е. компилятором не энфорсится) по причине того, что какой-то пермишен не указан. И быть готовым или обрабатывать этот exception или использовать какой-то Context.checkCallingPermission() перед каждым потенциально опасным вызовом (а их не так просто и найти, особенно если не с нуля код пишешь, а нужно модифицировать уже написанный код). Я лично вижу дофигища работы и еще и с неплохой вероятностью ошибки.

А теперь, если несложно обоснуй, каким образом у тебя почти нулевой эффорт получился?

[dotcom]

Там же в тексте написано, что программа "сама говорит". Я уверен, что программы с таким развитым интеллектом могут и сами решить проблему.

[Интеррапт]

Там же в тексте написано, что программа "сама говорит". Я уверен, что программы с таким развитым интеллектом могут и сами решить проблему.

Ну мне просто интересно послушать о решении. Люблю готовые решения.

[АццкоМото]

Т.е. теперь вызов
Vibrator v = (Vibrator) getSystemService(Context.VIBRATOR_SERVICE);
будет крешать программу с exception. Аналогично с сетью, файлами и еще десятком других возможностей.

Ты это знаешь или предполагаешь? Я сейчас за 2 минуты глянул - работа с сетью, например, не регулируется этой фичей. Работа с файловой системой - тоже. А ничего особенного приложение не делает. Пуш-сообщения не приходили, но зарегистрироваться никто не мешает.
Единственное действие, которое я быстро смог выжать из своей аппы - это copy/paste. Делаешь его - выскакивает в Апп Опс. Запрещаешь действие - и все, копи/пейст исчезают из приложения
Поэтому есть версия - просто версия, догадка, что никаких эксепшенов кидаться не будет. А управлять пермишенами можно будет только теми, которые могут gracefully послать нафиг приложение. Контакты прочитать? Да пожалуйста, их нету. Сообщение получить? Да оно просто не будет доставлено. Отослать? Либо молча не отошлется, либо какой-нибудь дженерик/нетворк еррор.
Еще раз, чисто предположение. Ибо ТАК сломать существующие приложения новым хендлингом пермишенов гугл не должен решиться

[Zorkus]

Я, в принципе,противник checked exceptions в Java (со времен EJB). Но подумываю, что может, экспешены которые выкидываются по пермишенам должны быть checked?

Вообще, на такие случай, в языке должна быть опция пометить заданный Exception class, скажем, PermissionAccessViolationException, compile-time аннотацией @Checkable. И кастомный процессор аннотаций должен при выставленной опции -DcheckCheckableException показывать их как ошибки.

Интеррапт, я поди велосипед изобретаю же, есть такое?

[Интеррапт]

Ты это знаешь или предполагаешь? Я сейчас за 2 минуты глянул - работа с сетью, например, не регулируется этой фичей. Работа с файловой системой - тоже.

Без понятия даже - факт, что Гугл пока вообще эту фичу "спрятал". Работа с файловой системой может и не регулируется, а вот чтение с SD карты - вполне может.

Поэтому есть версия - просто версия, догадка, что никаких эксепшенов кидаться не будет. А управлять пермишенами можно будет только теми, которые могут gracefully послать нафиг приложение. Контакты прочитать? Да пожалуйста, их нету. Сообщение получить? Да оно просто не будет доставлено. Отослать? Либо молча не отошлется, либо какой-нибудь дженерик/нетворк еррор.

В принципе у iOS подобный подход, если отказался дать читать контакты, то вернется пустой список контактов.

Еще раз, чисто предположение. Ибо ТАК сломать существующие приложения новым хендлингом пермишенов гугл не должен решиться

Да, я тоже не думаю, что Гугл так захочет все сломать, но с другой стороны Гугл публично и не выкатил эту фичу. Поиграюсь потом, напишу какое-то простенькое приложение, которое читает адресную книгу (ну или гугл example запущу) и через эту 3rd party app - отключу пару пермишинов. Посмотрим, выкинет ли оно с exception.

[Интеррапт]

Я, в принципе,противник checked exceptions в Java (со времен EJB). Но подумываю, что может, экспешены которые выкидываются по пермишенам должны быть checked?

Вообще, на такие случай, в языке должна быть опция пометить заданный Exception class, скажем, PermissionAccessViolationException, compile-time аннотацией @Checkable. И кастомный процессор аннотаций должен при выставленной опции -DcheckCheckableException показывать их как ошибки.

Интеррапт, я поди велосипед изобретаю же, есть такое?

Для этого нужно, чтобы методы в Android API были помечены подобными аннотациями, но ничего подобного там нет. Собственно и в стандартной Джаве такого нет. Например коннектишься ты к сети, а твой Security Manager запрещает это делать. Никак ты это в compile time не отловишь. Т.е. как бы твой поинт я понимаю, но обычно "системные" фреймворки такое не энфорсят.

[Zorkus]

Я, в принципе,противник checked exceptions в Java (со времен EJB). Но подумываю, что может, экспешены которые выкидываются по пермишенам должны быть checked?

Вообще, на такие случай, в языке должна быть опция пометить заданный Exception class, скажем, PermissionAccessViolationException, compile-time аннотацией @Checkable. И кастомный процессор аннотаций должен при выставленной опции -DcheckCheckableException показывать их как ошибки.

Интеррапт, я поди велосипед изобретаю же, есть такое?

Для этого нужно, чтобы методы в Android API были помечены подобными аннотациями, но ничего подобного там нет.

Написать утилиту, которая будет принимать джар на вход и список желаемых эксепшенов, и через BCEL или подобные тулзы модифицировать джар?

[Zorkus]

А вообще интересно попробовать..

[Ljolja]

на 0.0001%

А как ты посчитала? Например, у тебя есть код, который использует вибратор. Прописан пермишен android.permission.VIBRATE. А юзер его отключил. Т.е. теперь вызов
Vibrator v = (Vibrator) getSystemService(Context.VIBRATOR_SERVICE);
будет крешать программу с exception. Аналогично с сетью, файлами и еще десятком других возможностей. Сотни разных функций могут зависеть от десятков разных пермишинов.

I usually use try ... catch block in questionable cases. I'd put an assumption that you do have permission from the beginning as wrong. So, if the code is written with catch exception, there shouldn't be an issue, it you got a piece of code from somewhere in internet and it's not as great as you'd expect - don't complain .

прикинуть, какая строчка кода может вызвать exception (а это unchecked exception

I'd expect you make this yet while you write the code, not thereafter when something bad happened

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

А теперь, если несложно обоснуй, каким образом у тебя почти нулевой эффорт получился?

debug somebody else code is always more laborious work than to write your own