Денис И.

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

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

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

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

вы сами то понимаете, какой толк, какая практическая польза от максимально детализированных отчетов?
почему вас не устраивает скажем 10% погрешность в этих значениях?

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

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

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

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

давайте попробуем посмотреть на вопрос по другому : вы уверены что есть смысл экономить те 2-5-10кб текста на который уменьшится объем страницы из за этого неподгруженнооо дива ?
с сегодняшними скоростями на мобилках и тарифами - разницы видно не будет.

хотите экономить трафик - урезайте графику, больше эффекта будет. имхо.

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

мне кажется вы не верно ставите задачу.
и второе - какие у вас технологии?
и какой ajax вы делаете (перенаправление на новую страницу или какой аналог rest-запроса который отдает увам json)?(подозреваю что первое)

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

если второе, то генерируйте на сервере части html напрямую из параметров поискового запроса.

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

в следствии успехов маркетологов одного или другого лагеря.
и смены моды.

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

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

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

ну так вот: разница между 99% фреймворков джаваскрипта - это куча чепухи и рассказов про то как тут все клево, прогрессивно, моложежно. и практически ничего технически обоснованного. да, структуры разные, апи разный, но эта разница отражает как правило только вкусовщину их авторов и весьма редко имеет под собой хоть какую то техническую необходимость.

потому что это МОДА.
"не пытайтесь понять тараканов".

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

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

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

... ps: а jQuery при этом продолжает и продолжает выполнять 90% всей черной работы на 90% всех сайтов ;)

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

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

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

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

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

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

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

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

а по qt есть сертификация ? дайте ссылку, я попробую свои силы.

не курсы, но сертификация.

OCA Java. особенно в книге по подготовке к экзамену в изложении от Мала Гупта.
лучший курс ро оснрвам джавы.
вправояет мозг в верном направлении о том как работает джава машина.

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

вставлю свои 5 копеек. сумбурно, не все совсем все по теме буду излагать (но там будет ответ на вопрос .. вроде как) но надо понимать область применимости того, что хочет тов. Евгений .

Его желание "писать в веб так как десктоп" - мне очень даже понятно, и именно поэтому я фактически сделал свой фреймворк ( не на джаваскрипте, что вы, джава+вебсокеты, и совсем немного js). Но его область применения - тяжелый интерпрайз и интранет.

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

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

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

и так. "массовый веб" и "тяжелый интерпрайз" :

1. массовый веб.

тонны хомячков, тысячи примитивных запросов, простая логика (бизнес логика). на это заточено 120% современных веб-фреймворков, которые соревнуются между собой в синтакс-засахаренности, да функционально-фиче пригодности. микросервисы, stateless, rest-сервисы, json-туда-обратно - "... о как.. всем прияно...." и т.д. 90% последователей этих технологий не понимают даже основ проблем разработки больших систем на языках с динамической типизацией, готовы топить за самый модный в этом сезоне фреймворк, давить статистикой новых проектов на гихабе.... но да и фиг с ними, ... достаточно того, что те-же "хедлайнеры" - node.js - вдуплили эти проблемы и таки послали js подальше... тьфу - перешли на typeScript ( ибо статическая типизация - этт не закостенелость стариков, а вынужденная мера, совсем "не от хорошей жизни")... но тысячи хомячков любящих js ведь не могут ошибаться... и потому плодят мирриады js-фреймворков, каждый из которых применим в 2х случаях из 100. и отслеживают топ 10 попутярных в этом квартале языков программирования... ну ла ладно.

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

примеры: вконтактик, форумы, и 99% всех веб сайтов.
типичные технологии: php, одноглазый змей-питон, js, чудо руби, и все прочее и тд....

ps: и да, я ни коем разе не хаю js. я его люблю. но крайне рисковано применять js в объеме большем чем скрипт на 2 страницы. первый же рефакторинг и переаботка кода поломает все нафиг. на определноом объеме кода вы попадете в ситуацию, когда попытка имправить баг будет вность еще больше багов и вы не сможете это остледить.
то, во что сегодня превратили js и технологии на js - это страх и ужас, но да это моё имхо.


2. интерпрайз интранет
...и различные АРМ с веб-интерфейсом в локальной сети и сложной бизнес логикой

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

примеры: СЭД (системы документооборота), арм различных госструктур, арм различных операторов, и тд.

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

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

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

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

в общем вот тут идеи десктопного приложения очень как пригодились бы, но готовых технологий нет.
я вижу перспективу в использовании web-socket, но опять же, промышленных наработок и фреймворков нет.
самое близкое что так умеет - c++/Qt но у них скорее трансляция в веб интерфейса с++ приложения. в 1С аналогично - у вас одинаковый интерфейс "управляемой формы" и в веб и на десктопе.

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

---------
в общем я к чему: хотите использовать десктоп в веб? пишите например на qt/c++. у них есть технология трансляции в веб приложения написанного на c++. опять же, на вебсокетах все работает). хотите писать тяжелые арм на джаве для интарнет-интерпрайз-систем - присоединяйтесь к нашему закрытому тестированию (за сим в личку) или ждите публичного анонса. для шарпов ничего не скажу, имхо шарпы только для Unity-гемдева и пригодны(имхо), а как интерпрайз-технология они так и не состоялись.

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

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

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

или

- "тяжелый интранетовский интерпрайз" ( несколько сотен пользователй максимум, сложная логика работы каждого АРМ, тяжелые запросы отрабаиываюшие по десятку минут, запутанные бизнес-сценарии рабрты гуи, фоновые процессы на сервере.... ) - многие десктопные концепции, когда гуи должен рассматриваться так, как будто он локальный - просто жизненно-необходимы. попытки строить эти системы по технологиям из области "массового веб" - ... скажем так ..."чреваты" и в 90% случаев пооучаются либо костыльно убогими, если вообще работают, либо неповоротливыми в разработке и рефакторинге. не смотря на это, готовых решений и концепций всё еще пока практически нет, каждый изъгаляется как может. рынок достаточно закрытый, относительно массового веб : 99% этих арм и ас работают в наглухо изолированных от интернеса сетях.

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

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

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

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

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

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

декларативные шаблоны, "правильное" mvc (естественно правильное в мозгах автора-теоретика фреймворка), динамический рендерг элементов в больших списках... это все красиво только в формате курсовой после 2х семестров обучения, а когда у тебя в итоге в итоге ctrl-f на странице не работает и тебе клиент мозг ест, а все что ты можешь сказать - это "так устроен фреймворк отображаюй список элементов" - вот это уже совершенно не смешно, это джаваскрипт головного мозга авторов таких страниц, извините )))

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

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

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

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

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

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

а вообще троллинг засчитан, да)))
или автору надо идти учить "некоторые законы коммерции"))))

единственный известный мне способ отличить глобальную переменную
со значением undefined, от несуществующей переменной - это попытка присвоить её значение другой переменной. Вылетает исключение, которое мы перехватываем.

Причем надо пытаться взять значение самой переменной ( VAR ), а не через window ( window.VAR )

try { var aa=VAR; } // если тут отхватим исключение - значит у нас нет переменной VAR
 catch(e) { VAR =undefined; };  // присвоение  undefined значения - _определит_ переменную

// и далее её можно использовать 
var bb=VAR; // тут уже не вылетит исключение

заимствовав всю графику

Что значит "заимствовав"? если вы вытащили файлы из оригинальной игры (или напринтскринили их графику) и вставили в свою программу - то в самом страшном случае - к вам прийдет в гости "отдел К". Ибо нарушение аторских прав, если только лицензия на игру (код игры и контент) не свободные.

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

Копировать файлы - нельзя. Перерисовывать самим своими лапками - можно.

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

Следят ли админы подобных ресурсов за такими "мелочами" ?

Если к ним обратяться владельцы "аффтарских прафф" - то вы можете отгрести. Вплоть до пожизненного бана на данном ресурсе (гугл думаю так и попытается сделать).

Можно сделать таблицу в базе данных для них, где будут соответствующие поля "время", "дата", "текст", "путь к файлу" (Тогда отслеживать, что он остался прежним).
Но мне кажется, что такой подход не совсем верный, ведь напоминания — это объекты, с которыми удобно было бы работать, непосредственно обращаясь к ним, вызывая методы, например, note1.delete().
Как решить эту задачу с помощью объектов я не представляю. Допустим, в приложении мы создали таких несколько, но как быть дальше? Надо их где-то хранить. В той же базе данных?

Если вам удобно (да так в принципе и правильно, хотя и медленнее) работать с объектами а не с записями в БД - то для таких вещей есть такая штука как ORM. (у вас конечно простой случай, и потому работать с записями в вашем проекте - самое то. И тем более - если вы новичок - стоит разобраться с тем, как работать с БД напрямую. Но вообще, как только сделаете учебный проект с БД - , стоит понять, что в других сложных проектах - проблем с БД будет гораздо больше и будет сложнее и лучше осваиваться с "промышленными подходами")

В общем есть ORM. Если расшифровывать - это "модель/правила" которая/которые позволяют вам сохранять состояния объектов в БД и восстанавливать их.
А на практике - это набор классом которые делают за вас всю черновую работу по взаимодействию с БД (или тем хранилищем которое под ними лежит). И вы работаете не с БД, а с некой абстракцией, которая скрывает от вас что где и как она хранит в БД или том хранилище, которая ORM использует.

Т.е. вы говорите что-то типа - "О, мой ORM! дай мне объект типа 'МояЗаметка' c идентификатором 12345!" и он сам лезет куда-то в БД (куда именно - это его личные проблемы) и отдает вам обхект класса МояЗаметка которая заполнена данными заметки с номером 12345. А дальше - "чо хошь с ним, то и делай".

А как сделал все что надо (дургая его методы, меняя свойства или как ещё), - отдаешь его обратно своему ORM-слою ( ORM можно рассматривать как слой абстракции над БД или любым другим хранилищем ) - типа "на вот тебе объект, сохрани его в БД." - и механизмы ORM делают всю черновую работу по генерации SQL-запросов и всего прочего за вас.

В зависимости от того что от орм хотели создатели, ORM может или нет управлять структурой БД или пытаться вытаскивать свои объекты из ранее созданной структуры; управлять метаданными ваших объектов и (например) содержать или нет данные о том, как эти свойства надо отображать или нет.

В некоторых ORM есть кодогенератор - т.е. вы даете ему описания классов, а он вам генерирует код, который сохраняет классы в БД и восстанавливает оттуда. Часть ORM-механизмов работтают отталкиваясь от аннотаций - т.е. вы над каждым из полей которые хотите сохранять в БД надписываете его имя, тип, индексацию и другие параметры - так например делает Persistence API - но его нет на Андроиде, потому это не наш случай (да и работа через рефлекшен считается медленной).

Ещё могу дать 2 ссылки - на сравнительную статью ОРМ для Андроид и на мой сосбвтенный ОРМ-велосипед :
www.ninthavenue.com.au/android-orm-jpa
https://gitorious.org/unat/pages/SimpleORM_Overvie...
(последнее - "на правах рекламы". творение моё, но давно не обновлявшееся в публичной репе. Сейчас много изменений, как сдаим текущий проект - опубликую что поновее. В принципе, не столько для пользования, сколько вам - для освоения идей и выдачи конструктивной критики и вопросов. если что - спрашивайте - по UnAT я вам расскажу всё)))

Идею украсть нельзя. Нельзя украсть не материальную сущность. Читайте УК РФ)))

Программы, расcказы, изображения, фильмы и другие произведения - регулируются ГК РФ, в той части, где описывается авторское право и лицензирование.

Но и тут - идея - не попадает ни под лицензирование, ни под патентование.

Использование чужой идеи - не кража. Вот объявление себя как автора идеи - это уже ближе к краже, но все равно не кража - у вас же идеяя осталась - вы же её не забыли? ))

Теперь о практике. Произведения - коей является программа - вы можете защищать с помошью лицензирования. Авторское право на программу созданную работником принадлежат работодателю/заказчику (вы уж только извольте им заплатить иначе будет спорно). И далее в дело вступает авторское право.

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

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

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

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

И люди будут выбирать вас, а не подобия.

А страхи типа прог будет сидеть на мешке денег глядя как ва