Fedor K

Пользователи
  • Публикаций

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

  • Посещение

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

    15

Fedor K стал победителем дня 28 марта

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

Информация о Fedor K

  • Звание
    Продвинутый пользователь

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

489 просмотров профиля
  1. THTTPClient асинхронность

    @Akad, У Вас есть опыт работы с TNetHTTPClient компонентом или классом THTTPClient? Как и где вы это использовали? Что не понравилось? Какие трудности были? ... можете не отвечать, я уже глянул ваши предыдущие сообщения и смысла в продолжении беседы не вижу @kiz35196 Наиболее простой вариант Вы можете глянуть в этом посте.
  2. THTTPClient асинхронность

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

    Что конкретно печально в асинхронности клиента? На какой платформе? Если с примером - то вообще замечательно. п.с. Еще раз повторю, что нареканий со стороны работы асинхронности не было замечено в течении года в нагруженном мобильном приложении на обоих осях, Delphi Berlin Update 2.
  4. THTTPClient асинхронность

    1. Тут была идея подчеркнуть, что используется именно асинхронность самого THTTPClient, а не постройка своего велосипеда. 2. Можете дать пример кода вашей записи memo1? Или вы имеете ввиду обращение к UI без синхронизации?
  5. Легче и быстрее всего сделать свой стиль(и) TListBoItem, который содержит нужные вам контроллы и затем чисто добавлять новый элемент списка. делать солянку с фреймами или TVertScrollBox требует лишних телодвижений.
  6. THTTPClient асинхронность

    Можете немного подробнее, с чем связано это? Чем стандартная реализация асинхронности не устраивает? Используем около года в довольно сильно нагруженном приложении для асинхронных вызовов API, нареканий не было, Delphi Berlin Update 2. Или сломали реализацию в Tokyo?
  7. Что невозможно сделать на Delphi для Android?

    Вы наверняка меня не поняли, стоило использовать кавычки). Добавлять SDK можно, но это головная боль с "напильником" в руках. Если вы считаете, что все классно - не стану переубеждать. На том же Xamarin подключить SDK займет пару минут. Пока не будет создано расширений для IDE и небольшого рефакторинга исходников -> использовать сторонние библиотеки будут вызывать негативные эмоции. 1. Да, используется, но это очередной костыль, который не ахти сказывается на скорости работы. 2. Да, с 2016 года прекращен выпуск мобильных процессоров. Поэтому со временем этот пункт можно отметать. п.с. Давайте соберем список действительно невозможных на сегодняшний день вещей.
  8. Что невозможно сделать на Delphi для Android?

    Проблем с синхронизацией не было замечено ранее и пуля прилетает скорее всего из другого места. Сделайте нам демку пожалуйста.
  9. [Android]ListView и FullScreen

    Какая версия IDE? И сделайте пожалуйста демку для быстрой проверки.
  10. Close, Application.Terminate - я бы не советовал использовать на Android. Может оказаться такая ситуация, что часть приложения останется в памяти, а что-то уже убьется. В итоге заново запустить приложение без выкидывания из истории не получится и увидите только черный экран. Желательно обойтись без самоубийства на Android и лишь свернуть через SharedActivity.moveTaskToBack(True); Если все же самоубийство по плану, тогда лучшие средства TJProcess.JavaClass.killProcess(TJProcess.JavaClass.myPid); MainActvity.Finish; - как упомянул выше Равиль.
  11. Что невозможно сделать на Delphi для Android?

    1. Да, мы можем подключить новую версию SDK, но все обертки в исходниках остались старые. В итоге: поменял SDK -> заменил обертки -> наслаждаешься новыми "фичами" + количество оберток не резиновое. 2. Абстракция огромный плюс, когда инструмент доведен до идеала. В данный момент имеет плохую оптимизацию работы самого FMX + подарки от разработчиков = "у меня лагает" или "это валится с ошибкой, такого быть не может, на винде работает" и т.д. 6. Попробуйте отладку любого TJavaGenericImport класса, а потом возьмите этот же Java класс и посмотрите, что доступно при отладке в Android Studio. 7. Поддерживаются только ARM процессоры, про Intel и другие забываем, а это очень влияет на авторитет твоего приложения. 8. Проблема в скорости работы. Если все картинки хранятся в бинарном виде на самой форме -> значит при ее создании затрачивается больше времени и она уже в памяти, даже если эту иконку вы никогда не отобразите пользователю. + к этому: Крайне не удобно поддерживать версионность, когда требуется замена картинок. Если хранить только относительный путь в ресурсы - это делается с легкостью. 1. Сервисы тоже вряд ли можно назвать рабочими, но маркетологи с этим крайне не согласны. Поэтому согласно этому мы также можем запихнуть .jar классы widgetа в приложение и потом написать такую же оберку, как для сервисов и вызывать delphi код, но затраты не совместимы. 2. "Невозможно" сделать провайдер клавиатуры для системы. 3. Невозможно скачать стороннее SDK и использовать в своем приложении. Для FMX их никто не делает и делать не собирается. Хотим Facebook SDK -> запаситесь терпения и сделайте все сами или делайте обходные пути.
  12. Что невозможно сделать на Delphi для Android?

    Очередные холивары из разряда "мои проблемы никто не хочет решить за меня, значит Delphi плохой инструмент, давайте все перейдем в другую песочницу...". Минусы FMX есть и будут, от этого никуда не денешься, но в последнее время весь soft и продукты катятся в яму с кучей bugs даже от крупных компаний и корпораций даже спустя многие releases. Если на то пошло, то предлагаю все "невозможные" фишки периодически добавлять в первый пост и прикреплять решения, если они существуют. Проблемы FMX в следующем: Жесткая привязка к версии SDK, возможно сделано целенаправленно, чтобы пользователи обновляли лицензии год за годом. Позволяет разработчику не углубляться в особенности операционной системы, и не меняя мышления клепать свой "первоклассно рабочий VCL стиль" код и тонны компонентов под все платформы. Пропаганда "возьмите свой старый код и сделайте мобильное приложение" - маркетологи, вы в своем уме? Отсутствие достойных плагинов для IDE. Тот же Cn Wizard давно пора включить по дефолту. Неужели сложно добавить плагин для создания wrappers для java классов сразу в IDE? Разве сложно загрузить приложение прямо в маркет без ручного копирования? Отсутствует редактор manifest, plist как таковой. Вспоминается анекдот про танк и "доработать напильником". Многие достойные вещи делаются на голом энтузиазме сообществом, но почему-то только спустя много-много времени внедряются в коробку. Отсутствует нормальный debug на мобильных платформах, логами все не покроешь. Ограничения в ARM процессорах. Желание все хранить в .fmx, .dfm файлах, а не ссылками в ресурсы, как это принято в мобильной разработке. Это конечно обходится написанием своих менеджеров, но неужели сложно это продумать из коробки? Такое чувство, что пытаемся охватить как можно больше платформ по чуть чуть, чтобы кому-нибудь впарить свой продукт, а уже потом будем думать, как выкручиваться. FMX Canvas - ахиллесова пята. Не смотря на все это FMX является очень мощным инструментом и крайне приятным в умелых руках, если вы любите напильник (или мазохист). Средне статические проекты можно реализовывать не боясь, но для более серьезных вещей понадобятся знания нативной разработки, без этого никак. Если заказчик начинает разговор "я хочу такое, как в том-то приложении..." - значит без написания своей обертки или исправления исходников не обойдешься. FMX в последнее время активно развивается и спустя Х лет все будет у нас превосходно, просто не бегите за новыми версиями, а подождите Update 3 или используйте предыдущую версию (Berlin Update 2 все еще в соку). Другие кросплатформенные frameworks (Xamarin, Reac Native, RemObject, Native script, другие) тоже не лишены недостатков, но там слегка другие концепции и другая аудитория, кто лучше - покажет лишь время.
  13. ENetHTTPClientException

    Мне кажется вся проблема в том, что идет удаление объекты до окончания операций. Учитывайте, что процесс выполняется асинхронно: begin //тут лишь создается поток, в котором выполняется запрос lHttp.Post(Url, lSendData); Result := ''; end; // Result := lResponse.StatusCode = 200; finally //вот здесь ошибка. Нельзя удалять объекты, если действие еще не завершилось. Вы можете узнать об завершении прцоессса в событии OnRequestCompleted lSendData.Free; lHttp.Free; end;
  14. Посмотрел ваш пример, все зависания и вылеты с ошибками связаны с обращением к пустым объектам, попыткой обработать все в одном обработчике. Исправить клиент дело не благодарное, поэтому сделал пример по работе с TCP сокетом с возможностью автоподключения (тык). Проверил на нескольких устройствах, полет нормальный. Основные замечания: Не используйте FormActivate событие, тем более на мобильной платформе. Его обработка замораживает приложение. В примере посмотрите вариант обхода. TIniFile нет смысла использовать каждый раз для считывания настроек. 1 раз считали при старте приложения и больше к файлу не обращаемся. Хранить настройки в компонентах (edSettingHost.Text и т.п.). Создание свойства отнимет максимум минуту, а выгоду даст существенную. TCP сокет соединения следуют принимать как асинхронные, а не как запрос-ответ. Это предусматривает получение команды сервером, какое-то выполнение и лишь потом отправка на клиент. Поэтому попробуйте отказаться от использования GetFromServer. Сервер только запускал для проверки клиента, пару раз ловил outofmemory и access violation, закрыться тоже не захотел по-хорошему. Поэтому желательно его тоже довести до ума.
  15. Можете мне сделать тестовый сервер и клиент, чтобы я смог у себя проверить? Тогда мой ответ будет более детальным. А пока: Какой вы объем данных шлете по соединению? Чем вызвана потребность использовать именно сокеты? TimeOut никогда не ставьте большими. Indy работает по принципу блокировки сокета и всего потока в целом. Поэтому большое значение = зависание всего приложения = нежелательные результаты и зависание. Я ставил 100 мс для работы с маленькими пакетами. С такой задержкой доп. поток не обязателен. Если значения более 500 мс - нужно создавать отдельный поток и работать с сокетами в ней + синхронизация при обработке / отправке данных. TIdTCPClient на Andoid любит спать и не проверять входящий буфер. Поэтому вручную нужно вызывать по таймеру проверку типа: procedure T<какое-то имя класа>.Read; var sz : integer; lMsg : string; begin try TMonitor.Enter(Self); try if not Assigned(Client.IOHandler) then Exit; //Client = TIdTCPClient if Client.IOHandler.InputBufferIsEmpty then begin if not Client.IOHandler.CheckForDataOnSource() then exit; end; sz := Client.IOHandler.InputBuffer.Size; if sz <= 0 then exit; lMsg := Client.IOHandler.InputBuffer.ExtractToString(-1, IndyTextEncoding_UTF8); Client.IOHandler.InputBuffer.Clear; <какой-то обработчик входящего сообщения>; except on e : Exception do <какой-то обработчик ошибки>; end; finally TMonitor.Exit(Self); end; end; AntiFreeze - это мягко говоря "костыль" от Indy, использование его плохая практика. На мобильной платформе вряд ли он появится, хотя и реализуется не сложно.