Fedor K

При работе с API конкретной платформы советую использовать именно справку самой платформы. Находим реализацию на родном языке и пытаемся повторить тоже самое через wrappers от Delphi. 1 - это идентификатор вашего сервиса отличный от 0 (см. подробнее Service | Android Developers), т.е. можете использовать любые положительные цифры. По сути и обычные уведомления тоже содержат такой идентификатор, но это практически редко используется.

@Pavel M, Судя по вашей обертке класса и самой JAR: Нужно удалить все не статические методы из описания интерфейса наследуемого от JObjectClass: JUserClass = interface(JObjectClass) ['{A4B29440-8C8B-4C1F-A8E7-B7612D4FEEB4}'] function init(uuid : JString; secondName : JString; firstName : JString; inn : JString; phone : JString; pin : JString; roleUuid : JString; roleTitle : JString) : JUser; cdecl; overload; function init(uuid : JString; secondName : JString; firstName : JString; phone : JString; pin : JString; roleUuid : JString; roleTitle : JString) : JUser; cdecl; overload; end; У класса User нету конструктора по умолчанию, поэтому вызов такого кода вызовет ошибку: //неправильный вариант с ошибкой TestClass := TJUser.Create; //правильный вариант TestClass := TJUser.JavaClass.init( StringToJString('uuid'), StringToJString('secondName'), StringToJString('firstName'), StringToJString('phone'), StringToJString('pin'), StringToJString('roleUuid'), StringToJString('roleTitle') ); Если к проекту подключаете любые JAR файлы, то следите, чтобы вместе с ними были подключены и все остальные .jar библиотеки с классами, на которые ссылаются исходники. Например, в Вашем примере при вызове вышеприведенного конструктора первым делом выскочит ошибка: Вам нужно найти все такие подключения и найти сборки, в которых они валяются: Если в проекте в Android Studio включено копирование всех сторонних библиотек в папку libs, то после компиляции всего преокта практически все либы можно найти: папка libs; output папке проекта; папка Android SDK. п.с. Тему лучше перенести в раздел Android, так больше шансов получить помощь.

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

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

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

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

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

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

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

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

Какая версия IDE? И сделайте пожалуйста демку для быстрой проверки.

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

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

Очередные холивары из разряда "мои проблемы никто не хочет решить за меня, значит 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, другие) тоже не лишены недостатков, но там слегка другие концепции и другая аудитория, кто лучше - покажет лишь время.

Мне кажется вся проблема в том, что идет удаление объекты до окончания операций. Учитывайте, что процесс выполняется асинхронно: begin //тут лишь создается поток, в котором выполняется запрос lHttp.Post(Url, lSendData); Result := ''; end; // Result := lResponse.StatusCode = 200; finally //вот здесь ошибка. Нельзя удалять объекты, если действие еще не завершилось. Вы можете узнать об завершении прцоессса в событии OnRequestCompleted lSendData.Free; lHttp.Free; end;