ruslan

И после всего вышесказанного, скажите что я не прав

И я не говорил о том, что дельфи мертв. Сам поддерживаю несколько проектов.

Но новые проекты писать - уж простите..

Как минимум - недальновидно с точки зрения саморазвития и проф. роста.

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

Ответ очевиден: никому.

И никто меня не переубедит

Вас вообще понять не могу!

Все время критикуете RAD Studio и зачем тогда тут все время?

я вот отошел от C#, перекрестился и больше не хочу туда!

Да вот, захожу раз месяц - поржать

Чем шарп так "обидел" ?

Вакансии - главный показатель востребованности. Какой смысл мучаться с языком\фреймворком, который никому не нужен ? Пройдет пару лет, а вдруг умрет - все, ты никому не нужен. Поэтому нужно наваливаться на то, что будет жить еще очень долго: java\c#. Если что - дельфи, думаю, никто из нас не забудет

Ответ очевиден: никому.

И никто меня не переубедит

зашел называется....

парочка вопросов:

 

3-х звенка вещь профессиональная, и на ней нужен C# господа, да да, т.к. никакой это нафиг не RAD

что-то вот не понял. использую и delphi и c#. И что-то вот не вижу смысла в Вашем утверждении, ну ни грамма смысла. почему именно c# ? чем для 3-звенки c# лучше delphi ? причем тут rad вообще ?

 

был чуть ли не профи прогером по pl/sql. Позже я возненавидел оракл, т.к. познал какая отвратительная работа по администрированию его.

А ведь я насмехался над админами, особенно раздражала одинаковая ЗП, до тех пор...пока не столкнулся с администрированием сам...

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

сам который год на pl\sql. Поясните, пож-то, чем же администрирование oracle отвратительнее mssql ?

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

были профи прогером ? на pl\sql ? и ушли ? да не смешите...

в казахстане "профи" pl\sql разработчик может иметь ОТ 60 у.е.\час. В Беларуси таких оплат нету

 

На текущий момент прибыль дает больше VCL чем FMX...но я стараюсь сравнять неравенство, т.к. полюбил облака, ведь это свобода.

fmx  - свобода ? ну-ну...

п.с. сори за оффтоп. ну просто жуть как интересно стало

да еп..... 

ты хоть запятые поставь.

что значит "сервер клиента" ?

ниче не понял, что ты хотел сказать.

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

можешь по-подробнее объяснить ? тут с пунктуацией вроде норм, но я ничего не могу понять

ты вообще о чем ? что значит "app servera на голом sql" ? это вообще как ?

"

Обычно такие программеры используют MSSQL и ORACLE в качестве FoxPro видал массу примеров...

Порой диву даешься или шок, когда видишь, что дорогущий сервер БД используется на 0.0001%, а остальное делает "свой" сервер...

"

ты вообще понимаешь о чем я пишу ?

я не говорю использовать субд только как хранилище. 

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

но ! прослойка между клиентом и субд быть должна ! не стоит клиентам напрямую общаться с субд.

если миграция предполагается, либо возможна работа с разными бд в одном контексте, то ТЕМ БОЛЕЕ должно быть промежуточное звено !

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

да и не один адекватный сисадмин не пробрасывает наружу порты доступа к бд(если это только не шарашка с 10-15 сотрудниками).

блин . ну детский сад йомайо. о чем разговор то... элементарные вещи обсуждаем...

Не должен клиент напрямую коннектиться к базе. Должна быть прослойка. Пофигу: тонкая или толстая. Если бизнес логика предполагает миграцию на другую бд - толстая, есои нет - бизнес в пакетах\процедурах. Нельзя с клиента напрямую к бд идти. Должен быть rest-сервис. Пофигу - tcp\http, на дельфях он или на джаве, на питоне, на асп.нете... Клиент должен идти через прослойку. Имхо

а как без SSL шлешь на https ?

ето в 10-ке какая-то новинка ? где-то слышал, что там вроде indy щас https по-другому обрабатывает.

п.с. раньше без SSL не работало

пишешь tcp\http сервер, который общается с любой базой. выносишь апи наружу для клиентов, которые шлют запросы через тот-же tcp\http

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

клиент(а тем более мобильный) должен быть по-максимуму универсальным

имхо конечно...

че-то технологию попутали как топикстартер так и остальные...

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

возьмите любую базу MySql или Sqllite да и вперед, куда проще...никаких собственных серверов(велосипедов)

чаво ?

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

во-во ! про что я в принципе и говорю уже 3-ю страницу

 

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

не согласен есть разные типы приложений

 

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

Да просто тема интересная появилась Решил поделиться своим опытом

а если у клиента ios?

Блин, а че с ней не так то ? Вроде ж все расписал... Читай предыдущую страницу

но приложение то одно ? нет ?

один клиент - один универсальный клиент: один appId, один profile.

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

вроде все просто и понятно.

или я чего-то не понимаю ?

http://community.embarcadero.com/blogs/entry/download-an-image-in-background-with-android-services

 

пример сервиса на андроид

 

 

это да. просто человек спросил "как запустить приложение из сервиса". 

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

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

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

ну это только мое мнение.

наведу свой пример  мое приложение  подключается к сайту клиента собирает заказы  в настройках может быть несколько магазинов   приложение работает  с json формат строгий и не меняется  как в таком случае быть Push отпадает либо поднимать свой сервер и давать клиентам api  с которым они смогут работать оповещая  менеджеров магазина о заказах. на ведре можно поднять сервис а как быть с ios ? 

http://lfgonzalez.visiblogs.com/2014/11/radstudio-xe6xe7-remote-push-notifications-gcm-y-apns/

?

 

я боялся что прийдется делать что то подобное, бля...

 

)))) вам же master webs писал про NotificationCenter.

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

Также вам точно не нужны Push.

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

Затем по клику сообщения и откроется ваша программа...хз ну я думаю именно как то так пашут ватсапы и виберы.

Кстати в демках делфи у вас как раз про локальные есть пример.

 

это да. просто человек спросил "как запустить приложение из сервиса". 

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

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

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

ну это только мое мнение.

может кто-нибудь пояснить что значат вот эти строки кода в unit Data.DbxSqlite :

{$HPPEMIT LINKUNIT}

и

{$IF DEFINED(MACOS) or DEFINED(IOS)} // эта строка понятна
{$HPPEMIT ''}
{$HPPEMIT '#ifndef USEPACKAGES'}
{$HPPEMIT '/* automatically link to libsqlite3.dylib */'}
{$HPPEMIT '#pragma link "libsqlite3.dylib"'}
{$HPPEMIT '#endif'}
{$HPPEMIT ''}
{$ENDIF MACOS or IOS}

смирись 

IdSSLOpenSSLHeaders_static

 

Этот юнит использует как раз таки либу для SSL. Открой его, думаю разберешься 

 

 

P.S.: Вернулся что ли?

спасибо . 

p.s. ненадолго )

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

макосовский лог выдает след. ошибку:

Library not loaded: @rpath/libvpx.a

......

Вечер добрый. Прошу помочь, если кто знает как. 

Вопрос следующий:

как в fmx-приложении (ios) использовать внешние(external) библиотеки ?

В винде это .dll - вопросов нет, в linux\android это .so - проблем нет, в macos это .dylib - проблем нет.

В ios это .a файлы. Как их правильно подключать и использовать в проекте ? Про deploy знаю

Спасибо

никак

сначала ждешь первого апдейта, потом второго...

а потом ждать устаешь..

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

вот именно, что для ПРОТОТИПОВ !

ну... давай вперед ) удачи тебе )

давай-давай ))