Перейти к содержанию
Fire Monkey от А до Я

ruslan

Пользователи
  • Постов

    160
  • Зарегистрирован

  • Посещение

  • Победитель дней

    15

ruslan стал победителем дня 21 июля 2021

ruslan имел наиболее популярный контент!

Информация

  • Пол
    Мужчина
  • Город
    Minsk

Контакты

  • Skype
    ruslan-proto

Посетители профиля

10 417 просмотров профиля
  1. И после всего вышесказанного, скажите что я не прав И я не говорил о том, что дельфи мертв. Сам поддерживаю несколько проектов. Но новые проекты писать - уж простите.. Как минимум - недальновидно с точки зрения саморазвития и проф. роста. По поводу простоты реализации моб. приложений - да, но только простых приложений, и для заказчиков, которым пофиг на реализацию( напр. в корпоративном секторе. Им пофиг как там все работает, тупит, не тупит, абы работало). Для серьезного проекта с большой перспективой и разношерстной массой клиентов - в жизни бы не начинал писать на fmx. А какие надежды то были...
  2. Вас вообще понять не могу! Все время критикуете RAD Studio и зачем тогда тут все время? я вот отошел от C#, перекрестился и больше не хочу туда! Да вот, захожу раз месяц - поржать Чем шарп так "обидел" ? Вакансии - главный показатель востребованности. Какой смысл мучаться с языком\фреймворком, который никому не нужен ? Пройдет пару лет, а вдруг умрет - все, ты никому не нужен. Поэтому нужно наваливаться на то, что будет жить еще очень долго: java\c#. Если что - дельфи, думаю, никто из нас не забудет
  3. Ответ очевиден: никому. И никто меня не переубедит
  4. зашел называется.... парочка вопросов: что-то вот не понял. использую и delphi и c#. И что-то вот не вижу смысла в Вашем утверждении, ну ни грамма смысла. почему именно c# ? чем для 3-звенки c# лучше delphi ? причем тут rad вообще ? сам который год на pl\sql. Поясните, пож-то, чем же администрирование oracle отвратительнее mssql ? как разработчик(профи) может возненавидеть субд через несколько лет активного использования, из-за якобы "отвратительного" администрирования ? были профи прогером ? на pl\sql ? и ушли ? да не смешите... в казахстане "профи" pl\sql разработчик может иметь ОТ 60 у.е.\час. В Беларуси таких оплат нету fmx - свобода ? ну-ну... п.с. сори за оффтоп. ну просто жуть как интересно стало
  5. да еп..... ты хоть запятые поставь. что значит "сервер клиента" ? ниче не понял, что ты хотел сказать. хотя нет. одну фразу разобрать можно : "не каждый клиент захочет отправлять оповещения через левый сервер" можешь по-подробнее объяснить ? тут с пунктуацией вроде норм, но я ничего не могу понять
  6. ты вообще о чем ? что значит "app servera на голом sql" ? это вообще как ? " Обычно такие программеры используют MSSQL и ORACLE в качестве FoxPro видал массу примеров... Порой диву даешься или шок, когда видишь, что дорогущий сервер БД используется на 0.0001%, а остальное делает "свой" сервер... " ты вообще понимаешь о чем я пишу ? я не говорю использовать субд только как хранилище. если не предполагается миграция, то хранилище и (внимание) бизнес логика должна(по-моему) реализовываться на уровне субд. но ! прослойка между клиентом и субд быть должна ! не стоит клиентам напрямую общаться с субд. если миграция предполагается, либо возможна работа с разными бд в одном контексте, то ТЕМ БОЛЕЕ должно быть промежуточное звено ! зачем в клиент пихать логику ? ладно, не логику. зачем в клиент пихать провайдеры доступа к субд ? на разным платформах кучу нюансов. да и не один адекватный сисадмин не пробрасывает наружу порты доступа к бд(если это только не шарашка с 10-15 сотрудниками). блин . ну детский сад йомайо. о чем разговор то... элементарные вещи обсуждаем...
  7. Не должен клиент напрямую коннектиться к базе. Должна быть прослойка. Пофигу: тонкая или толстая. Если бизнес логика предполагает миграцию на другую бд - толстая, есои нет - бизнес в пакетах\процедурах. Нельзя с клиента напрямую к бд идти. Должен быть rest-сервис. Пофигу - tcp\http, на дельфях он или на джаве, на питоне, на асп.нете... Клиент должен идти через прослойку. Имхо
  8. а как без SSL шлешь на https ? ето в 10-ке какая-то новинка ? где-то слышал, что там вроде indy щас https по-другому обрабатывает. п.с. раньше без SSL не работало
  9. пишешь tcp\http сервер, который общается с любой базой. выносишь апи наружу для клиентов, которые шлют запросы через тот-же tcp\http я вот уже не в первой теме вижу желание некоторых людей завязывать логику на клиенте. зачем ? клиент(а тем более мобильный) должен быть по-максимуму универсальным имхо конечно...
  10. во-во ! про что я в принципе и говорю уже 3-ю страницу не согласен есть разные типы приложений парень, ты о чем вообще ? ты хочешь своим сервисом каждую секунду слать запросы ? ты хоть понимаешь, насколько быстро будет садиться батарея ? а еще это нифига не гарантирует стабильную работу, т.к. может пропадать сеть, падать уровень сигнала, другие сервисы могут полезть в это же время со своими запросами. Зачем это делать ? я не понимаю. Я же тебе предложил решение твоей проблемы. В чем трудности ?
  11. Да просто тема интересная появилась Решил поделиться своим опытом
  12. Блин, а че с ней не так то ? Вроде ж все расписал... Читай предыдущую страницу
  13. но приложение то одно ? нет ? один клиент - один универсальный клиент: один appId, один profile. один сервер - один универсальный контейнер бизнес-логики(постоянно чёто парсит), хранит инфу о клиентах(clientId, deviceId, сайты для парсинга), рассылает пуши. один ssl-сертификат. вроде все просто и понятно. или я чего-то не понимаю ?
  14. наведу свой пример мое приложение подключается к сайту клиента собирает заказы в настройках может быть несколько магазинов приложение работает с json формат строгий и не меняется как в таком случае быть Push отпадает либо поднимать свой сервер и давать клиентам api с которым они смогут работать оповещая менеджеров магазина о заказах. на ведре можно поднять сервис а как быть с ios ? http://lfgonzalez.visiblogs.com/2014/11/radstudio-xe6xe7-remote-push-notifications-gcm-y-apns/ ?
×
×
  • Создать...