gsm2015.ru - телефоны на android, simbian image

И вновь в эфире по многочисленным просьбам
Пост про разработку на андроид с абсолютного нуля!

Tagged with:
 

202 Responses to разработка на андроид с абсолютного нуля!

  1. XuaaTa:

    Печатаешь в гуголе «Android SDK» и читаешь.

  2. N0iam:

    Купи книжку Рето Майера, ее одной достаточно для того чтобы начать ходить под андроид

  3. YotTunes:

    по-английски можно?

  4. YotTunes:

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

  5. AobZZ:

    надоелтый же официальный мануал
    http://developer.android.com/training/in

  6. YotTunes:

    спасибо

  7. YotTunes:

    курю его и так.

  8. RasMilk:

    мне больше и не понадобилось.

  9. YotTunes:

    а твои приложения + исходный код можно как-нибудь посмотреть?

  10. N0iam:

    по английски я сам читал, больше ничего не понадобилось

  11. N0iam:

    ну это с учетом того что ты знаешь java и умеешь кодить

  12. YotTunes:

    ни того, ни другово. Поэтому и буду учиться.

  13. RedSnow:

    только никому не показывайте

    http://beta.appinventor.mit.edu/

  14. Moser:

    Кстати, я начал с Cordova (Phonegap).
    Чуть позже начал подтягиваться дальше.

  15. YotTunes:

    Он не на OSx?(

  16. YotTunes:

    На первый взгляд онлайн еклипс с больее красивой оболочкой. Плюсы/минусы?

  17. Moser:

    Там вообще пофиг. Это обёртка HTML5 под популярные платформы.

    Плюсы:
    + Быстрая разработка, при условии, что вы знакомы с HTML + JS + CSS (ну и поддержка jquery, например)
    + Относительно небольшой размер приложений (моё приложение a la twitter занимало 350 кб)
    + Допилить под другую платформу (например, Windows Phone, iOS, Bada) не составляет большого труда

    Минусы:
    — Приложение всё-таки под браузер, а не под Android.
    — Невозможность стандартный использовать андроидовский UI форм (во всяком случае я не нашёл, хоть и мало искал).
    — Так вы Java не научитесь.
    — У меня, например, тормозит при старте и временами вылетает. Мистика.

    Подводные камни:
    * Да, есть. Причём, в неожиданных местах. Например, я долго искал, как жедать ajax-запросы на сторонние ресурсы в интернете.

    Подытожим:
    Вполне годится для начала знакомства с Android для web-разработчиков.

  18. N0iam:

    т.е. использовать геолокацию, акселометр и все остальные хардварные ништяки так можно?

  19. Moser:

    Да, большинство там есть.

  20. RasMilk:

    Нет. 🙂 Их нет уже у меня. Я на дядю работал недолго.

  21. MaLoff:

    Я вот с этих уроков начинал http://developer.alexanderklimov.ru/andr… (тех, которые бесплатные оказалось достаточно)
    Ну и stackoverflow, само собой.

  22. DwsGood:

    Так всё же, хотел бы уточнить, как считает публика.
    Можно ли начинать создавать программы для android без элементарных знаний java, или нет?

  23. rin:

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

  24. DwsGood:

    мне так не показалось, до сих пор кажется, что не совсем понимаю, что такое ООП

  25. Simbian4:

    Гонишь? Кто же не знает Организацию Освобождения Палестины! Хезболла там всякая, хамас и прочая аль-каида…

  26. rin:

    Насколько я понял, нет опыта программирования вообще? Тогда немного сложнее, но тоже не беда. Читайте книжки, больше практики, смотрите как делают другие, и все получится.
    В любом случае что-то читать и не пытаться это сразу же проверить на практике не лучшая идея.

  27. Nibon:

    фишка в том, что многие желающие программировать хотят отдачи и видимых результатов прям тут и прям щас. В то время как надо лет пять убить на освоение принципов, прежде чем результаты будут заметно ощутимы. Лично меня такой срок останавливает.
    Накачал и видео, и книжек и прочего материала, а до этого в институте понять пытался — так и не понял ООП вообще. Какая уж там джава.

  28. rin:

    Пять лет — это вы конечно преувеличиваете, но, да, какое-то время потратить придется и не стоит ожидать, что первый результат будет очень качественным. Но это не главное, главное, что придет опыт и с каждым разом будет все лучше и лучше, а для этого нужно пытаться и как в любом деле шишек набьется множество.
    Насчет ООП, а зачем мы здесь все собрались? 😉 Спрашивайте, пишите посты, думаю никто помочь не откажется.

  29. Nibon:

    Расскажите «на пальцах» об основных принципах ООП. Полиморфизм там, наследование, инкапсуляция, вот это вот все, и нафиг оно нужно. С примерами на джаве или каком-нибудь выдуманном схематичном языке, если можно. Дело в том, что буквально нигде принципы ООП не рассматриваются сразу на примерах.
    Просто получается, что листинги языков верхнего уровня для меня — набор непонятных слов и символов, в то время как ассемблеры, древние бейсики, хтмлы всякие вполне понятны на уровне «вот в этой строчке делается то-то, а в этой то-то».
    Ну про ассемблер-то я и соврал, и не соврал — система ясна, но что она в целом делает — фиг его знает.

  30. rin:

    Мне кажется, что я понял откуда «растут ноги», постараюсь помочь в меру сил.
    У меня сегодня весь день scrum-планирование поэтому скорее всего напишу вечером.

    Насчет примеров, почитайте эту книжку говорят что она вполне хороша в этом плане.

  31. Arbef:

    три дня ставить эклипс? возьми idea community edition, в ней теперь есть android tools.
    Расскажи про свой опыт программирования, исключая css+html, но включая js(чтобы понимать с какого шага ты собираешься начинать). Ответь себе на вопрос зачем тебе разработка под android?
    //я не настоящий сварщик, и под ондроед вообще писал только две строчки в прожекте, и то в мавеновском pom.xml 😉

  32. N0iam:

    не, книжка предполагает что читатель очень хорошо знаком с основами ООП, так ты его только больше запутаешь

  33. FuAgreen:

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

  34. N0iam:

    почитай его вопросы выше, от того что он узнает где применять паттерн стратегия он не поймет чем инкапсуляция от полиморфизма отличается:)

  35. FuAgreen:

    первая глава там всё хорошо рассказывает

  36. Odoef:

    Зашел написать что поставил себе и поковырял Mono for Android — зачетная штука, для дотнетчиков самое то. Рекомендую, если че.

  37. N0iam:

    ну вот эта книжка передо мной, первая глава — паттерн стратегия, на примере уток, про основы ооп ни слова

  38. DwsGood:

    это он тебе ссылку на неё дал чтоб ты до вечера развлекался(:

  39. N0iam:

    зачем мне ссылка? я ее два года назад в бумажном варианте прочитал:)

  40. DwsGood:

    Там примеры есть на каком-то конкретном языке?

  41. N0iam:

    вообще на яве, но там не языку учат, я ее читал, и успешно применял полученные знания, когда на с++ кодил

  42. Simbian4:

    У них с дистрибуцией проблемы. Пока ковыряешься в IDE все хорошо. Когда начинаешь компилить дистрибутив — начинается…

    Поэтому пришлось изучать эклипс и ненавистную джаву в конечном итоге.

  43. Odoef:

    а что именно начинается? я пока ничего не заметил

  44. N0iam:

    а зачем изучать то, что не нравится?

  45. Simbian4:

    А потому что других приемлемых альтернатив программированию под Андроид пока не нашел.
    Пробовал HTML5, фигня какая-то выходит. С МОНО тоже не все гладко. Пришлось ковырять Джаву.

  46. Simbian4:

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

    В найтивном коде на джаве apk моей программы занимает 200Кб, с моновской библиотекой — 20Мб.
    Непорядок.

  47. Odoef:

    понял. я тоже удивился когда простой хеллоу ворлд занял 3 метра

  48. rin:

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

  49. rin:

    По просьбе расскажу немного об ООП программировании.

    Но начну издалека…

    printf
    Когда–то, как сейчас уже кажется в прошлой жизни, я преподавал программирование в СПбГПУ (Политех). И вы знаете, у большинства студентов была одна общая проблема: они не понимали зачем нужно ООП, не плюсы или минусы или что–то конкретное, а глобально “ЗАЧЕМ ОНО НУЖНО?”. При этом у всех уже был курс вводного программирования на православных “плюсах”, и многие считали, что в принципе ”плюсы” они худо–бедно знают, а вот ООП это какая–та дополнительная академическая примочка, без которой все и так работает…

    Знаете, я поразмышлял и пришел к выводу, что дело в printf’е! Конечно не буквально в нем, а в том, как он преподносится человеку начинающему изучать программирование. Попробую объяснить. Когда человек начинает изучать основы программирования, то, к сожалению, обычно это происходит так: в школе или вузе вам говорят, что есть разные языки, все они позволяют сделать одно и тоже, разница не существенна, а то и этого не говорят, в общем, мы учим Basic/Pascal/C/C++ или Fortran (привет Физфак).

    Ok, допустим С++ (привет ФТК). И первое что предлагается написать, конечно же, Hello World. А как это сделать? Необходимо в основной модуль программы добавить вызов нужной функции, конкретно printf. Я специально выделил эту страшную фразу “вызов нужной функции”. Вот где-то сейчас начинается путь человека в сторону противоположную ООП. Т.е. раньше он был ООП-нейтрален, но нейроны в мозгу уже начинают образовывать связь “Чтобы что-то сделать, нужно найти функцию, которая умеет это делать и вызвать ее” и наш человек потихоньку отправляется в занимательное путешествие, из которого не факт что удастся вернуться.

    Пока эта связь еще совсем слабенькая, но фразы подобной этой будут говориться месяцами или даже годами, поэтому представления нашего человека о программировании очень скоро станут сугубо в духе процедурного программирования. И его вины в этом почти нет, потому что никто ему еще не пытался сказать, что помимо процедурного подхода в мире вычислительных машин есть еще что-то другое. А не пытались не, потому что не знали (хотя есть и такие), а потому что считали, что упоминать об этом еще рано, нужно сначала понять “основы”. Я специально выделил последние слово в кавычки, т.к. считаю его неподходящим. Потому что преподавание таких безальтернативных “основ” вставляет мозги так, что после появляется целый класс людей не просто непонимающих основ, а считающих, что они все знают, при этом с такой кашей в голове, что невозможно себе и представить…

  50. Nibon:

    Гениально! Оставайтесь! Будете гениальным программистом планеты!

  51. Nibon:

    нужный img забыл приложить

    gsm2015.ru - телефоны на android, simbian размер 307x240, 26.90 kb

  52. FuAgreen:

    насколько я помню, там это всё было, и наследование, и полиморфизм, и интерфейсы.

  53. FuAgreen:

    решил в карму добавить, а там уже.

  54. N0iam:

    нет, не было

  55. XuaaTa:

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

    Я для себя считаю, что ассемблер в школе (своими силами) мне оч помог абстрагироваться от всей хуйни сверху. Учите асм! И начинайте с простых асмов (ISC), начинать с x86 — это вы башкой двинетесь.

  56. N0iam:

    зачем учить асм, если всю жизнь будешь работать с высокоуровневыми абстракциями (я, если что, асм знаю)

  57. Ihsed:

    x86 — сложный?

  58. YotTunes:

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

  59. XuaaTa:

    запутывающий. Я бы даже сказал, что он более высоко-уровневый, чем риски.

  60. XuaaTa:

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

  61. N0iam:

    крайне неубедительный пример. Я так и не понял зачем js программисту знать как работает риск процессор. С таким же успехом можно начать с изучения цифровой системотехники.

  62. XuaaTa:

    не бывает js программистов. Бывают либо профессиональные программисты, либо говно-кодеры «под jQuery». Во втором случае на хуй не надо.

  63. Ihsed:

    ISC Не кушал, надо попробовать.

  64. XuaaTa:

    просто в риске на любое действие одна команда. Там нету стопицот вариантов mov, есть только один. А все изьёбы с адресацией ты разруливаешь сам как хочешь. И то же самое про всё остальное. Стопицот видов условных переходов? Давай до свидания!

  65. YotTunes:

    что-то я не понимаю. Ваше мнение что если нет знаний ни в каком языке — то нахер не надо лезть в андроид?

  66. XuaaTa:

    моё мнение — учат кодингу неправильно. С этого ветка и началась.

  67. YotTunes:

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

  68. XuaaTa:

    а мы про это в этой ветке не говорим (:

    Пиши на яве, там ничего сложного. Если хошь, можем вместе — буду подсказывать чё куда и как правильно. Можно даже хэнгаут замутить на выходных и все желающие могут приобщиться к кодингу.

  69. YotTunes:

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

  70. XuaaTa:

    ну тады думай, будут вопросы — спрашивай.

  71. rin:

    …to be continued

  72. rin:

    Продолжение мыслей об ООП…

    А чем же все таки плох printf и процедурный подход?
    Ведь если подумать, то получается, что используй мы только его, мы бы в общем смысле ничего не потеряли, т.е. мы бы все равно смогли написать систему любой сложности (привет Linux). Все так, смогли бы написать все что угодно!

    Основной минус, что это сложно. Да, именно сложно. Сложно написать что–то новое, сложно разобраться в том, как работает уже написанное. Да ладно, printf это сложно? ) Сложнее чем могло бы быть! Как работает printf, в простом случае он принимает на вход строку. Просто? Пожалуй. А что если в этот printf нужно передать переменную, содержащую строку? А что если эту переменную нужно сделать динамически на основании какой–то другой строки и прочих входных данных? Не беда, для начала ее нужно создать. На занятиях говорили, что для выделения памяти используется malloc, наш герой погуглил и сделал что-то аля:

    char *buf = (char*)malloc(length); Плюс написал много кода завязанного на этот буфер. Но это не заработало, точнее заработало, но только в релизной версии, а дебажная начала падать или возвращать какой-то мусор в местах где еще только секунду назад работало. Погуглив еще наш герой нашел другой вариант кода, который называли более правильным с точки зрению C++, а так как наш герой программировал именно на C++, то его и решил попробовать:

    char *buf = new char[length]; Но и этот вариант в дебаге не заработал. Погуглив еще наш друг нашел вариант, который называли 100% рабочим:

    wchar_t *buf = new wchar_t [length + 2]( ); Заменив wchar_t на char у нашего героя все заработало и в дебаге и в релизе.

    Но спустя какое-то время пришла другая беда – строку стало нужно менять. В общем, повозился наш герой с реалоками и плюнул на все, его хороший друг Дима посоветовал не париться с этим и сделать просто char buf[256].

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

    Вот и сделал наш товарищ в итоге:

    char *buf = new char[большое число]( ); Правда потом и это не заработало, но это совсем другая история…

    Если разбираться, то первый и второй варианты у него не заработали, потому что он не выделил место под дополнительный символ окончания строки. В варианте с переименованием wchar_t все заработало, потому что на этот раз дополнительный символ он создал, но и еще, потому что он его правильно засетил (круглые скобочки в конце), без них массив был бы не проинициализированным и в дебаге бы это опять не заработало, с этим ему просто повезло. Но, правда “+ 2” он оставил напрасно, т.к. это относилось только к случаю wchar_t, где символ равен двум байтам, а в случае char – одному или чтобы не думать sizeof(char), т.е. имеем утечку, хоть и не большую. Со статическим буфером проблема в том, что он выделиться раз и навсегда хотя после завершения функции в которой он используется больше не нужен, а, следовательно, еще одна утечка. Ну и конечно в последнем варианте, он выделил ооочень много памяти, хотя она ему не нужна и при этом при выходе из функции скорее всего так ее и не очистил…

    Минусы искать в этом примере бессмысленно т.к. их там ооочень много, и при этом заметьте мы не дошли не до одной функции кроме самого создания буфера. А ведь есть еще сладкие strcpy, strlen и многие-многие другие…

    А не кажется ли вам что все это слишком сложно, несоизмеримо сложно относительно решаемой задачи? Думаю, конечно, всем так, кажется. Но хотите верьте, хотите нет, при чисто процедурном подходе особенно проще вам решить эту задачу не получится! Все дело в том, если мы имеем только данные (массивы, числа,..) но не объекты (Ура, наконец-то появилось слово объект )))), то нам просто негде хранить контекст выполняемых операций. Это значит, что данные сами о себе ничего не знают, а следовательно и не могут сказать об этом кому-то еще, например, нам…

  73. Lanef:

    а ты для 16 бит не кодил? Сегмент там, смещение, вот это вот все, ограничение в 64к.. Песня же! :)))

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

  74. Nibon:

    Прям сценарий фильма Гая Ричи, где до последнего абзаца не понятно, что все эти люди делают в кадре.
    Спасибо. Ждем континуя.

  75. YotTunes:

    я нихуя ни пони.

  76. rin:

    Это нормально. Смысл в том, что пока мы делали простую вещь мы 100 могли накосячить и никто еще не пытался нас остановить. Дальше я по простому объясню к чему это все.

  77. Nibon:

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

  78. YotTunes:

    нет конечно. но я пони, что могу посмотреть на код в хелловорлд и разлажить его по частям.
    Когда я начал делать лед куб, я нихера ни пони, куб я до сих пор не собрал, ибо по началу моя вина, потом мега32 подводила и мак, но транзисторы/резисторы — уже вполне разбираюсь. Как будет время, так и продолжу его делать.

  79. N0iam:

    да, а дизайнерам надо знать устройство катодной трубки и вертикальной развертки

  80. FuAgreen:

    во имя явы и сборщика мусора, аминь!

  81. N0iam:

    ну тут проблема не со сборкой мусора, а с выделением памяти, хотя в яве таких проблем тоже нет:)

  82. Simbian4:

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

  83. FuAgreen:

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

  84. N0iam:

    тогда не пиши на с++

  85. XuaaTa:

    и для 16 бит кодил и для 64.

  86. XuaaTa:

    дизайнерам надо учить математику и физику. Причём тут трубка, йопта?

  87. XuaaTa:

    процедурное программирование — это не сложно, это по-другому. Также как и функциональщина.

  88. N0iam:

    как причем, на чем нарисованные им пиксели отображаются? связь такая же как и js с цпу с риск архитектурой

  89. FuAgreen:

    я и не пробую.

  90. rin:

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

  91. SukMsk:

    ходить под андроид[x]

  92. SnaSnow:

    оу-е. Ты только не бросай это дело, пожалуйста 🙂

  93. RehGood:

    Ты выдаешь свое видение мира как аргумент.
    Давай тебе дам другой факт — жили были ^W обучали в свое время две специальности: 2201(вычмашины, системы, комплексы, сети) и 2202(программирование) в одном из ВУЗов.

    Факт — сиськомотехники-железячники программировали лучше, нежели чистые программисты.

    Под лучше — я имею в виду совершенно объективные вещи, как чистота кода, более экономичные и быстрые программы, количествопрограмм, которое использовалось реально, а не для галочки-зачета.

    И это, довод — что «дизайнеру все равно на чем нарисованные им пиксели отображаются в заказе» — это как раз довод гуманитария-jquerera, php-шника в самом плохом смысле этого слова.
    Если действительно все равно — то, простите, это тот самый человек, которому нравится название профессии «дизайнер», но который нихрена реально в ней не шарит.

  94. XuaaTa:

    дизайнер — это инженер. В зависимости от инженерной направленности ему может быть полезно знание устройства CT. Например, дизайнер телевизоров без знания особенностей CT сделает хуйню, которая будет перегреваться и от которой будут вытекать глаза у пользователей. Если ты дизайнер паровозов, то на хуй тебе CT?

  95. XuaaTa:

    просто процедурно решать задачи, быстро и качественно решаемые ООП — глупо. Также, как решать с помощью ООП то, что решается функциональщиной на раз-два. Тоже ногу отстрелишь себе (:

  96. rin:

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

  97. N0iam:

    ты сейчас работаешь программистом за деньги?

  98. N0iam:

    а если ты пишешь сайты, то нахуй тебе устаревшая риск архитектура?

  99. SukMsk:

    > потому что он его правильно засетил (круглые скобочки в конце)

    расскажи поподробнее

  100. SukMsk:

    > т.е. имеем утечку, хоть и не большую

    утечка, это если он забыл сделать delete buf;

  101. SukMsk:

    а еще точнее, delete [] buf; но для байтов сойдет

  102. SukMsk:

    а всё, нашел

    new-initializer:
    ( expression-listopt )

  103. XuaaTa:

    слушай, на хуй ты вообще кодингом занялся?

  104. rin:

    Конечно, имелось ввиду что будет выделено большем чем нужно. Ночь такая ночь )

  105. YotTunes:

    Парни! Остановитесь! Я не просил делать клуб любителей понастольгировать по Паскаль!
    А вот есть у меня идея, давайте я вам дам код хеллоу ворлд, а вы мне скажете что обозначает данное слово или знак.

  106. N0iam:

    ну в отличие от тебя я в этом разбираюсь:)

  107. XuaaTa:

    в чём? В CT? Ну молодец!

  108. RasMilk:

    В последнем стандарте можно забыть про уборку памяти. 🙂 Там наконец-то авто поинтеры сделали частью стандарта.

  109. Nibon:

    главное, не под себя

  110. Nibon:

    просьба хорошая, но останавливаться не стоит. Лично мне интересно понять уже наконец-то основы ООП.

  111. XuaaTa:

    тебе какое: классовое или прототипное?

  112. YotTunes:

    Ладно. пожалуй начну.

    С манифестом мне все понятно кроме интентов.

    ntent-filter>
    ctivity>

    Интент фильтрует окна по мере их поступления или важности? Где можно найти их списки и категории?

  113. YotTunes:

    в начале их основные различия, пожалуйста.

  114. YotTunes:

    (скобка откр)activity
    android:name=».MainActivity»
    android:label=»@string/title_activity_ma in» (скобка закр)
    (скобка откр)intent-filter (скобка закр)
    (скобка откр)action android:name=»android.intent.action.MAIN » / (скобка закр)

    (скобка откр) category android:name=»android.intent.category.LA UNCHE» / (скобка закр)
    (скобка откр) /intent-filter (скобка закр)
    (скобка откр) /activity (скобка закр)

  115. RasMilk:

    la uncher de android

  116. XuaaTa:

    различие такое.

    Классовое ООП — это когда у тебя есть чертёж меча, ты в него смотришь и куёшь меч как написано. Если тебе нужен меч с хуем вместо ручки, ты рисуешь новый чертёж на прозрачной плёнке, на которой рисуешь хуй вместо ручки. При наложении на оригинальный чертёж ты видишь полностью вечь меч с хуем и куёшь новый исходя из полученного чертежа.

    Прототипное ООП — тебе дают меч, ты на него смотришь и куёшь точно такой же. Но вдруг решаешь, что мечу нужен хуй. Ты отламываешь у своего нового меча ручки и втыкаешь хуй. При этом оригинальный меч не меняется. Теперь ты можешь ковать мечи двух видов. Или не ковать, а забухать. В классовом ООП бухать нельзя.

  117. Nibon:

    и то, и другое, и можно без хлеба.

    Я хрен знает, на самом деле.

  118. Nibon:

    пипец набор символов)

  119. XuaaTa:

    интент — ебанутое слово. В других ОСях это называет СОБЫТИЕ (event). Просто обычно есть глобальные события (сменилась тайм-зона, села батарейка) и локальные (юзер тыкнул в твою собственную кнопку и никто кроме тебя об этом не знает). А тут есть интенты (глобальные события) и эвенты — локальные.

    На глобальные события (интенты) можно подписываться двумя способами — традиционным во время ран-тайма и через XML. Штука в том, что если твою софтину ни разу не запустили, то ни на что ты подписаться не можешь, поэтому и сделали обходной вариант через XML. Отличное решение!

    Следовательно, события (интенты) никак не фильтруются. Либо юзер сделал что-то, либо нет. И если он что-то сделал, то это что-то одно. В конструкторе ты можешь узнать чё была за причина вызова активити и написать юзеру, что он — хуй. Или не хуй. Или не написать, например.

    Также интенты используются для кросс-процессной фильтрации. Я хуй знает как это на русском. Но суть в том, что любая софтина может узнать кто на какие интенты подписался через XML. Например, android.intent.category.LAUNCHE — это такой специальный интент, который до софтины твоей никогда не дойдёт. Но ланчер загружает список всего софта и смотрит кто такой интенет прописал, того и иконку показывает юзеру. Google Maps, например, показывает несколько иконок для разных действий (Maps, Navigation и т.д.), а ключ для Titanium Backup на android.intent.category.LAUNCHE не отзывается, потому что он не программа, а ключ.

    android.intent.action.MAIN — это эвент запуска софтины при нажатии на иконку android.intent.category.LAUNCHE. Можно сделать иконку без запуска программы, лол.

  120. XuaaTa:

    в Java — классовое. В C++ тоже. А в JS и Self — прототипное.

  121. Nibon:

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

  122. YotTunes:

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

  123. XuaaTa:

    окай, что тебя конкретно интересует? Могу на выходных какую-то простенькую софтину сделать и рассказать поэтапно чё па чём. Можем надоелшыть хэнгаут на Г+ и сделать всё вместе дружно через вебки в онлайн и рилтайм.

    Есть желающие на хэнгаут и совместное обучение?

  124. YotTunes:

    Угу. Значит когда action — эт интент (ивент) для дальнейшего действия, а когда категория — то можно не печатать???
    Потом надо бы знать про public и private.

  125. RehGood:

    Ну как сказать. В свое время работал. СОМ, потом cgi, web, php. Потом вообще из программирования ушел на совершенно другую работу. Но вселенная забавно крутится — таки сейчас рядом с кодингом. Хотя и не программистом.

  126. XuaaTa:

    фильтрация там по данным интента. То есть смотри. Есть интент android.content.Intent.ACTION_SEND. Видел в софте кнопки Share? Вот когда ты тыкаешь Share, софтина посылает интент ACTION_SEND. И прилепляет данные, которые она шарит. Google eader шарит текст, галлерея шарит картинки, аудио-плейер шарит музычку. И если ты в своей софтине хочешь принимать только картинки, потому что делаешь инстаграмм, то ты в фильтре говоришь, что понимаешь только картинки, а текст и музыка давай до свидания.

    Вот здесь пример XML для принятия текста, одной картинки и кучи картинок.

    Категории используются для дополнительного тагретинга, так сказать. Например, чтобы добавить свою софтину как пункт меню в настройках телефона, ты делаешь категорию android.intent.category.CATEGOY_PEFEE NCE, а чтобы софтину было видно в ланчере — android.intent.category.LAUNCHE. Интент при этом один и тот же — android.intent.action.MAIN то есть запуск программы.

    Я, кстати, затупил там, android.intent.category.LAUNCHE — это не интент, а категория. Извини, у меня под вечер глаза ебуцо (:

  127. Nibon:

    ну учитывая то, что и элементарных понятий современного программирования, считай, что не знаю, то нужно всё.
    И да: я желающий.

  128. XuaaTa:

    оок, так и запишем.

  129. YotTunes:

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

  130. N0iam:

    ну вот когда будете нанимать веб программиста, дайте ему в качестве тестового задания написать что-нибудь на асме под риск архитектуру. Когда найдете такого тогда и поговорим:)

  131. YotTunes:

    а @Override используется для того чтобы освобождать память откуда угодно?

  132. rin:

    В продолжении…или пол шага до наследования

    Объект
    Повторюсь, работать с низкоуровневыми данными сложно, т.к. никто нас не защищает от самих себя. Эти данные предоставлены в наше полное распоряжение, и мы можем делать с ними все что угодно, даже то, что не предусмотрено системой или задачей, например, неправильно выделить память. Мы словно держим Magnum калибра 357 и вот-вот выстрелим себе в ногу забыв снять с предохранителя. Хотя хотели всего лишь забить гвоздь.

    Но и это половина беды, т.к. воздействовать на эти данные тоже сложно. Потому что для функций данные являются просто входными параметрами. Поэтому сложно понять, а какую функцию можно/нужно использовать сейчас. Т.к. сами данные ничего сказать не могу, то поэтому это приходится решать нам. Если вернуться к примеру со строкой, то чтобы скопировать одну строку в другую нам нужно думать, а что вызвать strcpy, strncpy или если у нас юникодный вариант строки их wchar аналоги, или мы программируем для MS и у нас есть еще strcpy_s, _mbscpy или вообще _tcscpy который в зависимости от установки флагов препроцессора превращается в один из вышеперечисленных. А как узнать, какие функции доступны, кроме как проглядеть заголовочный файл? А ведь функции еще и взаимодействуют друг с другом, например, в strncpy нужно передать размер итогового буфера, а как его посчитать strlen, wcslen, _tcslen,…

    В общем люди подумали и пришли к простой мысли: “А пусть данные сами это разруливают”. Но т.к. простые данные ничего делать не могут, то пусть это будут некоторые абстракции над данными “объекты”, которые берут на себя все мороку по поддержанию своего собственного внутреннего состояния, да еще и предоставляют пользователю набор методов доступный только для этого типа объектов.

    И появился его величество Объект! Который в большинстве языков представлен в виде классов. Т.е. на смену ужасному char[] пришел, например, string. И все сермяга в том, что этот string и миллионы подобных ему взяли на себя целый пласт вопросов, освободив программиста от необходимости каждый раз думать “А как сделать это?”. Т.е. вместо Магнума наконец-то дали молоток.

    string где–то глубоко в себе скрывает тот же char[], но делает он это так хорошо, что пользователь этого объекта об этом просто не думает. Т.е. времени думать над тем, как заставить это работать нужно меньше, а освободившееся время можно потратить на что–то более полезное, например, на само программирование.

    string str = “Hello World”; Просто. Добавим восклицательный знак: str += “!”; Тоже просто. А какой новый размер: str.length() и т.д. Т.е. этот объект взял все заботы о вызовах нужных функций на себя, а нам предоставил только конечные высокоуровневые методы, спрятав от нас все тонкости реализации. Он сам выделит память, сам ее очистит, сам найдет и заменит нужный символ, он столько всего сделает сам, что в сравнении с byte[] будет казаться манной небесной.

    Т.к. этот объект сосредоточил в себе весь набор доступных методов, то нам теперь нет необходимости лазить черт знает где, в поисках подходящего метода, т.к. мы всегда можем спросить сам объект “А что ты умеешь?”.

    И главное, когда у нас появился объект, то с этого момента мы можем попытаться забыть о вызове какого–то конкретного метода, мы можем попытаться думать, оперируя только абстрактными объектами. Т.е. если я, например, работаю с файлами, я не хочу думать о том, куда передать HANDLE полученный от ::CreateFile(…). Какой такой хэндл, что это вообще такое? Я хочу иметь объект файл, который все сам умеет и все знает. Хочу создать файл, возьму объект директория и скажу ему: “Создай файл”.

    Это интуитивно понятно! Методы сосредоточены в четко определенных местах, где им самое место. Т.е. я не найду метод “создать папку” внутри объекта “файл”, т.к. это не логично, и я даже не буду пытаться этого сделать.

    Чисто технически т.к. данные внутри объекта должны существовать пока существует объект, то объект может их уничтожить, когда будет уничтожен системой. Т.е. в C++ он может сделать это в деструкторе, например, в C# в реализации IDisposable. На практике это значит, что в коде вида:
    void func()
    {
    string buf = “Some long string”;
    }

    Нет нужды думать о том, что нужно очистить buf, т.к. это может и должен сделать сам объект.

    И вот у нас постепенно почти все стало объектом, взаимодействие стало проще и понятней, но оказалось, что чтобы наделить объект новыми свойствами нужно написать новый объект, что получается накладно и неудобно. Поэтому люди подумали и пришли к мысли, что можно сделать еще проще…

  133. rin:

    Ммм и что?

  134. YotTunes:

    Да я про то, что там тоже про ООП, но в другом стиле.) Ты когда свой рассказ продолжишь уже?

  135. rin:

    Ну, да, только очень не конкретном )
    Осталось непосредственно само наследование, полиморфизм и инкапсуляцию рассказать, собственно что изначально и хотели, но нужна была хоть какая-та вводная. Не думаю что сегодня скорее завтра.
    Пока писал, понял что если это делать не «на коленке», более аргументировано и развернуто, то можно страниц 20 написать, но для нашего бложика это конечно перебор.

  136. YotTunes:

    Эссе от Романа, мы подождем, главное научи. Кстати, не сочти за обиду, но я твоей приложенькой на С3 не могу пользоваться, а вот куда писать про всякие беды я не помню, а еще хотелось бы знать что на твоей блоге происходит.

  137. N0iam:

    а я нормально на с3 пользуюсь, правда пришлось внести кое-какие изменения в кодл

  138. YotTunes:

    есть апк? Вообще у меня сейчас весело, каждый килобайт на счету. Приехал в Германию, универ инет не подключил мне еще, а безлимитного трафика на мобильники я не нашел. Максимум — 3гб в месяц. За два дня я потратил 1.1гб. Поэтому хорошее блогоприложенько на с3 очень не помешает.

  139. rin:

    : А в чем проблема?

  140. N0iam:

    апк можно по новой собрать. Но я передалал лэйауты, у меня был с внешним видом косяк. Правда это было довольно давно, может уже пофиксил все.

  141. YotTunes:

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

  142. rin:

    Отчет отправил?

  143. rin:

    Да, вижу. Непонятно. А так всегда происходит?

  144. RehGood:

    А в чем подвох-то?

    Мол риск-архитектура — это нечто экзотическое?
    Но тот же AV — у него ISC ядро, ему куча лет, программированием под него занимается достаточное количество людей.
    И, безусловно, умение программирования железа на низком урвне всегда очень весомый плюс при принятии решения о приеме программиста под.NET, например.

    Хорошо, довод с другой стороны. Мне интересна Ваша оценка, всего лишь 2 цифры:

    1. Какой % asm-программистов может писать для web? (php, jquery, mysql)?
    2. Какой % веб-программистов может писать на низком уровне? (c, asm, c++)?

    Мой вариант ответа — первая цифра не менее 80%, вторая — не более 5%.

    Но в этом случае логически получается, что практически каждый asm-программист является и web-программистом, но не наоборот.
    Каждая принцесса — женщина, но не наоборот.

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

    В топку.

    Нужны профессионалы, которые понимают, что оптимизация — это технология.

    И главное — куда не копни, без базовых знаний — никуда не денешься.
    Именно одинаковая база гарантирует взаимопонимание в команде и стабильность и предсказуемость результатов. И чем глубже базис — тем в большей степени сиё проявляется.
    А что глубже, чем понимание работы компьютера начиная с туннелирования электронов и выше и выше?
    Вебер тупо не понимает, какими физическими законами диктуютя граничения на код. Он не понимает как работает TCP-IP. точнее, понимает, но начиная с какого-то уровня. Хорошо, если он слышал про эталонную модель OSI. Он считает, что ему это просто не надо.

  145. rin:

    ok, как ты относишься к тому чтобы списаться как-нибудь в посте и отладить?

  146. YotTunes:

    я всегда за.

  147. rin:

    Зер гуд, я напишу когда будет свободное время.

  148. YotTunes:

    а я как дурак могу сказать что 1 и 0 это разность потенциалов во времени?

  149. RehGood:

    Не понял, разверни мысль.

  150. YotTunes:

    Я про то что в физическом плане туннелирование электронов — подача/не подача определенного напряжения = 1 и 0. А дальше устройство запоминает комбинацию из 8 таких действий и тд.

  151. RehGood:

    Ну строго говоря, между туннелированием и логическим состоянием пропущен ряд промежуточных действий.

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

    Если триггеры строить на других принципах — хоть пневмо — ил гидро физических законах, то более верхние уровни можно даже оставить прежними.
    Стимпанковский компьютер, у которого процессор + память занимают объем звезды смерти — каково?

    Кстати, о вопросе веб-программиста и знания стандартов.
    Задайте на собеседовании соискателю должности веб-программиста вопрос: сможет ли он расшифровать аббревиатуру FC. Тоже покажет глубину уровня знаний.

  152. YotTunes:

    Компьютерное ISO.
    А в чем смысл булевой логики? (Вики не предлагать)

  153. YotTunes:

    Я тут медленно прихожу к понимаю что смысл мне ясен как и что зачем следует, но вот как это записать — мне не ясно. Где бы я мог посмотреть пошаговые примеры кодинга?

  154. OogVelo:

    еще есть startandroid.ru для тугих типа меня. Доступне, диетичне для мозга.

  155. YotTunes:

    я и забыл что я у них пдвку на первые 100 уроков скачивал. спасибо. вроде в топе про них писали.

  156. OogVelo:

    неудобно, полчаса искал текствью.

  157. YbaZlo:

    полное говно

  158. RehGood:

    Не компьютерное, а именно интернет-iso.
    Смысл? Оч. хороший вопрос.

    Булева логика — это раздел математики, который позволяет достаточно просто оперировать значениями 1 и 0.
    С помощью булевой алгебры можно выразить требуемые состояния «на выходе» при определенных состояниях на «входе». А затем упростить получившиеся многоэтажные уравнения (как пример — метод карт карно, про который я говорил выше). А затем, например, вообще все уравнения выразить через один-единственный элемент И-НЕ (xor). И из этих железных ксоров построить любой сложности. Или перейти к физической реализации алгоритмов. А там уже рукой подать до понятия процессор.

    Можно сравнить с математикой римских цифр — где сложение, вычитание и умножение настолько сложны, что решение системы квадратных уравнений — это удел героев.
    Переход к позиционной математике (в средней школе — с основанием 10) позволяет решать эти системы совершенно в промышленных масштабах, достаточно знания — как это вычисляется, вычисления и упрощения просты. В математике римских цифр рассчитать, например, ну пусть 5-ти этажный железобетонный дом — задача нереальная по требуемым человеко-временным ресурсам.

  159. YotTunes:

    я правильно понял, что булева логика занимается тем, что если есть 8 бит в одной последовательности и 8 в другой, то через ксор проведя два байта на выходе будет один, но тот, который тебе нужен? а в ксоре происходят вычисления что и зачем удаляется. (Как я помню их там вообще 6 разных логик вроде)

  160. RehGood:

    ыыы…ээээ…мнээээ…

    у меня ощущение, что я не подойду тебе в качестве учителя.
    извини, бро

  161. YotTunes:

    .( ну вот зачем рассказывать и оставлять так вот?

  162. Nibon:

    Тебе точно сюда. Разжевано, внятно и понятно.

  163. YotTunes:

    так бы сразу. спасибо.

  164. SukMsk:

    Бля, опять плюсую аукса.

  165. XuaaTa:

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

  166. XuaaTa:

    хэнгауты пишутся автоматом. Но на этих выходных не выйдет — вчера до сегодня праздновали ДР. Я ещё не раздуплился. Завтра подумаю над тем, чтобы такое рассказать для нубов чтобы было интересно и полезно.

  167. Lanef:

    главное начать, не важно с чего, но начать. А там уже по ходу пьесы разберешься 😉

  168. YotTunes:

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

  169. Ruoed:

    попробуй Эккеля почитать Thinking in Java.

  170. N0iam:

    лучше это для начала Эккеля после

  171. Nibon:

    спасибо вам обоим, почитаю.

  172. Lanef:

    так вперед. Для решения такой задачи тебе нахрен ненужна ява, хватит какого-нибудь PhoneGap..

  173. rin:

    В продолжение топика

    Т.к. у меня не запланировано много времени отъел сапорт LD, то предлагаю ускориться и сократиться…

    Наследование
    Ok, у нас есть объект. У нас есть тысячи объект. Нас это устраивает. Но в какой–то момент времени мы понимаем, что чего–то в объекте не хватает.

    В MSDN есть отличный пример: система отслеживания ошибок (bug tracking system). Например, TFS. Это такое решение от MS, более функциоальная чем просто bug tracking’ая система, но это сейчас не важно. Этот TFS умеет оперировать объектами разного рода, это баги, таски, истории, спринты и т.п. Очевидно, все эти объекты имеют что–то общее: время создания, автор, описание… Но и имеют различия, так Бага содержит поле отражающее ее критичность для продукта (severity), а объект Релиз по понятным причинам этого поля не содержит, зато в нем есть перечень Фич входящих в этот релиз.

    Вопрос как это реализовать? Т.е. у нас есть набор объектов, пересекающийся частью функционала или если быть точнее имеющие базовые свойства и нам бы хотелось реализовать это наименее затратным способом. Здесь есть три основных варианта:

    1) Написать объекты от начала и до конца независимо. Т.е. дать одной команде реализовать объект Таска, другой Бага и т.д. Но здесь сразу всплывает множество проблем, во–первых, копипаст, т.е. реализация логики, например, по хранению создателя этого объекта будет проделана множество раз. Во–вторых, из–за копипаста менять одно и тоже придется множество раз, т.е. хранили создателя строчкой, потом решили хранить сидом, менять придется во всех объектах. В–третьих, т.к. объекты будут иметь разные типы, то и использовать будет их неудобно т.к. помимо дублирования самих объектов придется продублировать и методы, принимающие их на вход, т.е. какой–нибудь CreateItem будет существовать в нескольких вариантах, для баги, спринта и т.д.

    2) Другой вариант это реализовать базовый объект и пробрасывать вызовы от специализированных объектов в этот базовый. Т.е. написать что–нибудь аля:

    SomeMethodAInsideBug()
    {
    return _commonObject.CommonMethodA();
    }


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

    Конечно же это не все проблемы примеров 1 и 2, но для общего представления думаю достаточно.

    3) Унаследовать каким–то способом возможности базового класса. Вот в этом и есть базовый смысл наследования: декларировать возможность наследования свойств базового объекта дочерним. И это в данном случае, пожалуй, лучший вариант.
    Т.е. мы можем сказать, что наш класс Bug наследник WorkItem, и поэтому Bug получает доступ к возможностям базового класса WorkItem, который в свою очередь реализует общие для разных item’ов возможности.

    На практике все немного сложнее, т.к. кое–где бывает множественное наследование, базовый класс может хотеть спрятать свои внутренние методы от дочерних классов и т.д. Но это не важно, важно понять, что базовый класс “делится” своими свойствами с объектами унаследовавшимися от него. Поэтому если мы вдруг захотим ревизовать в TFS новый item SomeItem со всеми возможностями базовых элементов, но с одним единственным дополнительным полем SuperField, то для этого нужно будет написать всего лишь аля:

    class SomeItem : WorkItem
    {
    string SuperField;
    }

    И, как уже было сказано, экземпляр такого класса SomeItem будет иметь возможности класса WorkItem. Т.е. можно будет сделать что–нибудь аля:

    someItem.GetTitle(); — Где GetTitle метод базового класса, возвращающий заголовок item’а.

    Проблема с множеством методов тоже отпадет, т.к. если был метод ShowTitleToUser(WorkItem item) какого–то класса, взаимодействующего с UI, и этот метод принимал на вход объект типа WorkItem, то ничего переделывать не придется, т.к. в этот метод можно запросто скормить объект типа SomeItem и все будет работать, именно по тому, что SomeItem тоже является WorkItem’ом.

    Полиморфизм
    Наследование это хорошо, а что делать, если в базовом классе есть свойство/метод, поведение которого хотелось бы переопределить в дочернем? Т.е. не добавить новый метод, а изменить поведение существующего. Для этого и применяется полиморфизм (много форм).

    На практике это работает очень просто, использую синтаксис языка можно разрешить переопределение методов базового класса. Т.е., например, у WorkItem’а есть метод GetItemName(), возвращающий строку с именем item’а (бага, таска,..) и этот метод вызывается, например, в методе ShowTitleToUser(…) из предыдущего примера. Как поступить? Просто. Переопределим метод GetItemName() в дочерних класса, и теперь, когда у объекта WorkItem, внутри метода ShowTitleToUser(…) спросят “А какое у тебя имя?” метод вернет, не то что возвращал WorkItem изначально, а то, что определил реальный объект, например, бага (класс Bug).

    И это еще не все, WorkItem может не просто разрешить переопределение методов, а может обязать дочерний класс их реализовывать. Т.е. если вы унаследуетесь от WorkItem’а, то вам придется реализовывать такие методы.

    Подобные подходы применяются повсеместно, т.к. позволяет думать не частностями и конкретными реализациями, а высокоуровневыми объектами. Так, например, ShowTitleToUser(WorkItem item) все равно какого конкретно типа item, что позволяет спроектировать этот метод еще до конкретных реализаций класса WorkItem.

    Еще один пример, которым я попытаюсь проиллюстрировать полиморфизм. Пусть есть класс ConfigurationManager, который считывает имя пользователя и пароль из объекта конфигурация (Configuration). В классе Configuration два метода GetUserName() и GetUserPassword(). Так вот, можно спроектировать ConfigurationManager так, что он не будет зависеть от конкретной реализации. Т.е. если сделать эти две метода переопределяемыми, то можно будет скармливать в ConfigurationManager совершенно произвольные классы, реализующие эти методы. Так в одном случае это будет какой–нибудь FileConfiguration, берущий данные из файлов, а в другом DbConfiguration берущий их из базы. При этом ConfigurationManager изменять не придется, в особенности это актуально, если этот мэнэджер не может быть модифицирован, например, если он реализован в сторонней библиотеке.

    Инкапсуляция
    Если говорить коротко, то это сокрытие и защита внутреннего состояния объекта. Т.е. объект обладает каким–то внутренним состоянием и его задача: предоставить пользователю ровно столько, чтобы он не лез во внутреннюю кухню самого объекта и как следствие не мог ее повредить.

    Например, если объект хранит какую–то информацию об активности пользователей, например, это система аудита. Пользователя можно добавить вызовом метода addUser(string userName), то этот метод скрывает от пользователя, как конкретно хранится список пользователей. Т.е. если он хранится в массиве, то этот метод может пробежаться по массиву перед добавлением и вернуть ошибку, сказав, что такой пользователь уже добавлен или проверить его существование в AD или еще что–нибудь. Этого было бы нельзя сделать, если бы объект предоставлял пользователю сам массив, т.к. пользователь смог бы в него добавить/удалить что захочет без какой–то валидации, а это как раз то с чего мы начинали эти посты, т.е. с проблемы, когда пользователь работает с низкоуровневыми данными и когда высока вероятность ошибиться.

    Другой пример. Пусть есть класс, отвечающий за некого удаленного агента. У такого класса есть много полей, в том числе поле содержащие информацию о времени последнего запроса от агента. В конфиге хранится настройка, через какое время бездействия считать агента недоступным, по умолчанию 15 минут. Так вот вместо того чтобы заставлять программиста сначала запрашивать у класса агента последнее время доступа, потом идти смотреть эту настройку и на основании этих данных вычислять доступен он или нет, можно добавить метод IsAvailable() – который делает все тоже самое, но скрывает от конечного пользователя этого объекта эту внутреннюю кухню.

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

  174. YotTunes:

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

  175. SapRain:

    Чуваки, а где ищут андроид-девелоперов? Хотелось бы блогера, но, в целом, если есть надежные знакомые, я бы познакомился.

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

  176. SapRain:

    спасибо!

  177. YotTunes:

    В самой блоге напиши или на job.блог, там всяко народу побольше.

  178. rin:

    Класс считай это синоним объекту. Собака — класс, Робот — класс и т.п. Метод — имеющиеся рычаги воздействия на метод, т.е. например у класса Робот есть метод Включить. На псевдокоде это будет что-то аля:

    obot.TurnOn()

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

    obot.Say(‘I am obot!’)

  179. rin:

    Метод — имеющиеся рычаги воздействия на класс кончено же

  180. YotTunes:

    сразу бы так. я бы с удовольствием сейчас продолжил штудировать фонгэп или эклипс, но учеба съедает, а интернет грузит только текст. Поэтому если не лень, попиши что-нибудь еще, про то, например, что если oboy.TurnOn() ?
    здесь описываются события какие-то и хрен знает как их записывать.
    ?;

  181. rin:

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

  182. YotTunes:

    ладно.) спасибо и на этом.

  183. Nibon:

    Вот тут я перестал что-либо понимать. Ну да ладно.

  184. rin:

    А конкретней, что именно было не понятно?

  185. Nibon:

    Примеры) То ли у меня логика и внимание пробуксовывают, то ли текст второпях написан — некоторые моменты выглядят как вклейки. Или в текст просятся какие-то пропущенные абзацы.

    Сами определения я прекрасно помню, но понимать мне их надо будет уже на практике, видимо.

    Тупой.НичегоНеПонял.Забил(‘Потом пойму’);

  186. rin:

    Хм, а все же, что неясно, например, в примере с WorkItem’ом?

  187. Nibon:

    С наследованием методов всё более-менее понятно. А вот в тексте про полиморфизм..

    Не ясно откуда я вообще могу узнать методы классов и их свойства?
    Опечатка или нет — «этот метод вызывается, например, в методе»?
    «Как поступить?» — вот тут чего-то не хватает. Наверное, текста, в котором объясняется, почему вообще надо как-то поступать.

  188. rin:

    Узнать можно заглянув в их исходных код, в SDK (аля MSDN) или IDE (аля Visual Studio) может подсказать какие методы доступны в классе.

    Например в Android у классов отвечающих за создание окошек (Activity) есть метод OnCreate, который отвечает за создание стандартного окна. Так вот, если ты не хочешь чтобы у тебя все окна были одинаковыми черными прямоугольниками, хочешь не хочешь, но этот метод придется переопределить и написать там код делающий вид характерный для твоего окна, например, кнопка в середине.

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

    Сам Android переделывать из-за нового окна как не сложно догадаться не нужно. Он как оперировал Activity там ими и оперирует, но в момент вызова очередного метода OnCreate система поймет, что этот метод реализован в каком-то кастомном классе и нужно вызвать его, а не базовый.

    Т.е. отвечая на вопрос Как поступить? Сначала понять чего ты хочешь! Т.е. если ты хочешь изменить вид окна начать гуглить как это делается и узнать что нужно переопределить какой-то метод. Или зная что за стандартное окно отвечает Activity, найти описание этого класса, и посмотреть какие методы у него доступны и что можно ими сделать.

  189. Nibon:

    спасибо, стало яснее

  190. NasSnow:

    спасибо! Я так и знал что меня наебывают. Оказывается, я уже очень давно понимаю ооп. Только терминов не знал.

  191. NzbYes:

    Perfect timing! Нам сейчас пытаются про ООП рассказывать на лекциях, но…

    Вот, кстати, скоро чуваки с XDA сайт откроют про разработку под Android

  192. Nibon:

    практически любые подобные учебные курсы подразумевают наличие знания java.

  193. 448Milk:

    они забыли паддинги и тд, какой позор

  194. Nibon:

    прикольно. Ещё бы английский на слух воспринимать.

Добавить комментарий