kami

{$IFDEF offtop}Мсье знает толк в извращениях {$ENDIF}

Кирилл, это вечная дилемма между удобством/красотой приложения, задействуемыми ресурсами и скоростью его работы. Разумеется, анимации влияют на загрузку процессора. Но вот так однозначно сказать - это не употребление, а именно "зло" - нельзя. Если есть возможность - запустите под Windows под профилировщиком (AQTime Standart, например) - сразу увидите, какие методы максимально грузят процессор. Вспоминаются жалобы в плеймаркете (не реклама) на яндекс.карты - в одной из версий приложение разряжало аккумулятор вхлам, даже постоянная зарядка не спасала. Разработчики что-то сделали, внешне ничего не поменялось (вроде), но проблема ушла.

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

Извините, но на ум сразу приходит фраза "чукча не читатель"? Зачем советовать компонент человеку, который плохо разбирается в вопросах межпрограммного обмена, если вы "ничего не знаете"? Нет "там" выбора "интернет". Network - это не "интернет", а "сеть". Читаем последний абзац из http://docwiki.embarcadero.com/RADStudio/XE6/en/Using_App_Tethering

Разве Tethering работает через интернет? Емнип, он способен обнаруживать "коллег" и подключаться только в одной подсети.

В дополнение: если мне не изменяет память, то обработка всех queued-методов производится (если продолжаем разговор в терминах Windows) ДО обработки всех сообщений. Т.е. если вы сделаете (к примеру): PostMessage(...) TThread.Queue(...) то код в queue будет выполнен раньше, чем обработка WM_ из PostMessage. Уж не помню, где это я на такое напоролся, но дело было в iOS

TThread.Queue(nil, procedure begin my_code end); ?

Подразделяем задачу. Устройство ведь будет не одно, так? Соответственно, необходимо (простейший путь, но не совсем правильный) помимо координат передавать на сервер еще и какой-нибудь идентификатор, по которому сервер сможет однозначно определить - кто прислал ему координаты. Итого, получаем: 1. Клиентское приложение, содержащее idHTTPClient. По таймеру отправляется GET-запрос с параметрами: идентификатор, Latitude, Longitude. Пример привел krapotkin в посте №8. 2. Сервер, до которого можно достучаться из интернета. Предыдущая компания, в которой я работал, не заморачивалась с доменными именами. Купили белый IP и на своем роутере настроили переадресацию портов: этот порт - на этот компьютер, этот - на другой (или тот же). В любом случае, самое главное условие - до сервера должна быть возможность достучаться "извне". Как это будет сделано - вопрос к системному администратору вашей компании, это его головная боль. 3. Десктопное приложение, которое будет отображать данные на карте. При дальнейшем совершенствовании вы захотите отображать историю (трек движения), применять различные фильтры и т.п. Поэтому лучше сразу разграничить: серверу-серверное, клиенту-клиентское. Алгоритмы простые: для клиента в принципе, уже все описано в п.1 для сервера. Он должен содержать какой-либо компонент, работающий с http. Для обеспечения совместимости разработки - пусть это будет idHTTPServer (хотя я предпочел бы mormot). В Design-time прописываете ему нужный порт, а на событие приема вешаете свой обработчик. Этот обработчик: "выдергивает" из полученного GET-запроса переданные идентификатор, широту и долготу, пишет их (желательно в базу, а не текстовый файл - данных будет ОЧЕНЬ много, вы ведь потом захотите к примеру построить трек движения устройства...). десктопный клиент. Пусть он также общается с сервером по http. Бросаете на сервер второй idHTTPServer, назначаете ему другой порт и событие приема. Десктопный клиент (на начальном этапе) будет отправлять только один запрос - "дай мне текущие координаты и имена всех активных устройств". Пусть это будет тоже GET-запрос, без параметров. Сервер в ответ на этот запрос шерстит базу, выдергивает последние данные активных устройств, запихивает их в xml / json / protobuffer / etc. и отправляет десктопному клиенту. Десктопный клиент, получив эти данные, парсит их и запихивает на карту. Самое сложное здесь (с точки зрения более-менее опытного программиста) - видимость сервера. Но, как я и говорил - это забота сисадмина (если он у вас есть). Вроде, все расписал. Остаются только под-задачи: как получить координаты, что писать в обработчиках на сервере, как и где хранить на сервере данные, как их выбрать и куда запихнуть, чтобы отдать десктопному приложению, как распарсить данные на десктопном клиенте и запихнуть их на карту.

Исходя из того, что вам посоветовали взять за основу сетевого обмена Indy, а вы пытаетесь что-то сделать (судя по всему) на TClient/TServerSocket, т.е. игнорируете сказанное вам - чем сообщество может помочь? И кстати, "сокеты", если имеются ввиду idTCPClient/ServerSocket работают на Android, насколько я знаю.

Кстати, если "приложение на компе" планируется запускать исключительно под Windows, я бы посоветовал остаться на VCL и задействовать mormot-фреймворк, он работает с http-драйвером Windows и я за все время его эксплуатации ни разу не встречал проблем (в отличие от Indy и ICS).

В первую очередь определитесь, в каком виде сервер хочет получить содержимое вашего Edit. И хочет ли вообще. Есть как минимум два варианта отправки (по http(s)) - метод GET и метод POST. Anyway - до сервера должна быть возможность достучаться. В общем случае - сервер должен иметь белый статический IP. Если используется только локалка (пусть даже и с разными подсетями) - тут проще. Берете Indy, десктопное приложение будет выступать сервером (idHTTPServer), а мобильное приложение - клиентом (idHTTPClient). Клиент отправляет данные через idHTTPClient1.Get|Post, а сервер в событии приема данных ловит это и обрабатывает.

Не работал с ВК.API, но судя по ответу - ваше приложение не считается авторизованным, и Indy с https тут ни при чем, т.к. 401 - ответ, полученный от сервера vk.com

AsyncPro заточен на работу с COM-портом средствами API Windows. Неохота устанавливать этот компонент, но я уверен, что зависимостей от FMX.xxxx модулей у него нет, как и зависимостей от VCL.xxxxx. Максимум - используется Forms для Application.ProcessMessages и Controls для возможности размещения на форме. В остальном переписывание не должно потребоваться. Раз вы умудрились положить компонент на FMX-форму, значит он уже скомпилирован и готов к использованию в FMX (поскольку Parent имеют разные типы), все остальное, скорее всего - ваши недочеты.

Поменяйте объявления в uses, компилятор вам же подсказывает - что на что надо заменить. Но я что-то сомневаюсь, что самому компоненту нужны формы. Скорее всего, вы пытаетесь скомпилировать приложение, использующее компонент.

Это зависит не от индейцев и не от FireMonkey, а является общей проблемой сетевого обмена Ваш сервер спрятан за NAT, т.е. нет прямого соответствия между внешним IP и локальным. Поэтому клиент и не может достучаться до него "извне". Возможные варианты решения: сделать серверу белый IP (есть такая услуга у провайдеров, в т.ч. и мобильных) Сделать промежуточный сервер, который будет сидеть на белом IP, а исходный сервер и клиент будут подключаться к этому, таким образом они оба будут клиентами. Если доступен роутер, через который сервер "смотрит" в интернет - можно пробросить на этом роутере порт извне напрямую на локальный ip сервера. Да, в качестве примеров работы "за NAT" вы можете привести Skype, TeamViewer, Ammyy и т.п. Но они все используют метод 2. Еще есть вариант (кажется, не помню точно, давно этим не занимался) - DynDNS.

uuxyyz, прошу прощения - помогло. Тем не менее, я заменил получившиеся dcu в папке lib, после чего удалил файл из корня проекта и заново сделал билд проекту - изменения подхватились + я избавился от проблемы "глобально", а не в рамках своего проекта. Хотя... тут как посмотреть, конечно... В общем, изменения в Studio\15.0\lib я оставил, но и файл в папку проекта вернул. Спасибо, вопрос решен!

Думаю, это не поможет. Если я правильно понимаю, то при релизной компиляции будут использоваться dcu из пред-компилированных папок. Соответственно, dcu модуля FMX.WebBrowser подхватит не измененную dcu FMX.WebBrowser.IOS. Сейчас я напрямую подключил в проект измененный модуль из /Source/fmx/ . Но чтобы проверить правильность "подхватывания" мне сейчас нужно провести дополнительно кучу действий, чем я, собственно, и занимаюсь. Изменения (еще раз обращаю внимание - это относится к XE7 Update1) ChangesForFMX.WebBrowser.IOS.txt

Доброго времени суток, коллеги! Пришлось несколько изменить код стандартного модуля FMX.WebBrowser.iOS для корректной работы при загрузке локальных файлов. Вопрос: какие действия надо предпринять, чтобы изменения подхватывались приложениями без дополнительных телодвижений? В VCL это делалось достаточно просто - меняем pas на нужный, подключаем путь в SearchPath, пытаемся скомпилировать, после чего получившийся dcu заменяем в /lib и убираем путь из SearchPath. Предыстория (не обязательно к прочтению): Несколько недель я бился над проблемой вылета приложения при работе с WebBrowser.Navigate(local_file_path). Вылетало далеко не всегда, но удалось выявить закономерность и после долгих мучений, я нашел виновника торжества - метод TiOSWebBrowserService.DoNavigate(...). В нем проводились хитрые манипуляции с пересборкой URL, которые иногда приводили к nil в одной из переменных. Через десятые руки и внутренности iOS это все передавалось в TiOSWebViewDelegate.webView, где и возникало исключение. До метода TiOSWebViewDelegate.webView(webView: UIWebView; didFailLoadWithError: NSError); дело даже не доходило, call stack виновника, само собой, не показывал. Кому интересно, что получилось (не гарантирую идеальность кода) на XE7 Update1: Простите, кнопка "код" почему-то удаляет весь код при сохранении сообщения, несколько раз пробовал. Пришлось воспользоваться "цитатой". А цитирование удаляет некоторые строки из кода... Update: видимо, движку форума не нравятся два слеша, которые используются в этом коде. Пришлось удалить код...

Вот с с++ не помогу. Но не верю, что пара строчек кода так сложно портируется.

В том же примере есть два события - одно возникает при показе клавиатуры, а другое при скрытии. Программно скрыть - вас в яндексе с гуглом забанили? Первая же ссылка ведет на эту тему http://fire-monkey.ru/topic/41-kak-ia-mogu-skryt-pokazat-klaviaturu-pod-android/

В озвученном вами примере ScrollableForm в том числе получается высота виртуальной клавиатуры в методе FormVirtualKeyboardShown

Более того, она и меня ввела в заблуждение Я посмотрел (когда начинал работать с FMX) код Free, увидел, что при ARC он будет пустой и успокоился на этом. А комментарии всякие читать... не барское это дело Вот и попался...

xenon54, согласен. Но сам объект от этого никуда не денется - как минимум, его будет держать Parent. Кстати, только сейчас обратил внимание на "compiler translates.....". Весьма удивился, если честно. Я почему-то был уверен, что всё от TObject и выше (дженерики не в счет) реализовано именно кодом в .pas файлах procedure TObject.Free; begin // under ARC, this method isn't actually called since the compiler translates // the call to be a mere nil assignment to the instance variable, which then calls _InstClear {$IFNDEF AUTOREFCOUNT} if Self <> nil then Destroy; {$ENDIF} end;

вместо всего вышеперечисленного при удалении делать MainMenu.Release; MainMenu:=nil; .Free на мобильных платформах не делает ничего.

Платформа способна Есть неплохой набор нативных компонентов D.P.F. Components. Смотрим, как реализовывается такая штука в Studio, смотрим как реализованы всяческие интерфейсы и компоненты в D.P.F. и портируем необходимый функционал/интерфейсы/структуры по образу и подобию. Да, это (наверное, даже очень наверное) сложно. Но думаю, что т.к. задача не особо распространенная, то реализовать ее кроме как Вам некому...