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

Лидеры

  1. Brovin Yaroslav

    Brovin Yaroslav

    Администраторы


    • Баллы

      5

    • Постов

      2 124


  2. Savage

    Savage

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


    • Баллы

      2

    • Постов

      12


  3. krapotkin

    krapotkin

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


    • Баллы

      1

    • Постов

      2 213


  4. kami

    kami

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


    • Баллы

      1

    • Постов

      643


Популярный контент

Показан контент с высокой репутацией 19.04.2018 во всех областях

  1. Для получения инфо о доставке пуша, надо использовать XMPP Вот гугломануал Firebase Cloud Messaging XMPP Protocol ПО для отправки сообщений (комп, сервер и т.д.) <-- обмен по протоколу XMPP ---> Сервер гугла FCM <-------> Андроид устройство использовал IdTCPClient Host fcm-xmpp.googleapis.com Port 5236 IdTCPClient.Connect вот сценарий >>> - отправка на FCM <<< - ответ от FCM >>> здороваемся (IdTCPClient1.IOHandler.WriteLn ) <stream:stream to="gcm.googleapis.com" version="1.0" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams"> <<< (IdTCPClient1.IOHandler.Readln) <stream:stream from="gcm.googleapis.com" id="000000000000" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client"> <<< <stream:features><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>X-OAUTH2</mechanism><mechanism>X-GOOGLE-TOKEN</mechanism><mechanism>PLAIN</mechanism></mechanisms></stream:features> >>> логинимся <auth mechanism="PLAIN" xmlns="urn:ietf:params:xml:ns:xmpp-sasl">Base64Encode(sender_id@gcm.googleapis.com+ApiKey)</auth> <<< <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/> >>> отправляем обязательный пакет <stream:stream to="gcm.googleapis.com" version="1.0" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams"> <<< <stream:stream from="gcm.googleapis.com" id="000000000000" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client"> <<< <stream:features><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/><session xmlns="urn:ietf:params:xml:ns:xmpp-session"/></stream:features> >>> отправляем обязательный пакет <iq type="set"> <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"></bind></iq> <<< <iq type="result"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"><jid>sender_id@gcm.googleapis.com/000000</jid></bind></iq> >>> отправляем сообщение <message><gcm xmlns="google:mobile:data">{"message_id":"20","delivery_receipt_requested":true,"to":"DeviceToken","data":{"title":"Message title","message":"Message text"}}</gcm></message> <<< получаем подтверждение, что гуглосервер принл сообщение от нас <message><data:gcm xmlns:data="google:mobile:data">{"message_type":"ack","from":"DeviceToken","message_id":"20"}</data:gcm></message> <<< получаем подтверждение, что сообщение доставлено на андроид-устройство <message to="sender_id@gcm.googleapis.com" from="devices@gcm.googleapis.com" type="normal"><gcm xmlns="google:mobile:data">{"data":{"message_status":"MESSAGE_SENT_TO_DEVICE","device_registration_id":"DeviceToken","message_sent_timestamp":"1524141512313","original_message_id":"20"},"time_to_live":0,"from":"gcm.googleapis.com","message_id":"dr2:20","message_type":"receipt","category":"com.pushTest"}</gcm></message> Ключ АПИ и идентификатор отправителя надо брать в консоли Firebase https://console.firebase.google.com/u/0/project Подробно описано тут http://blog.rzaripov.kz/2017/02/firebase-android-ios.html
    2 балла
  2. Если честно, тут задача на мой взгляд в неправильном подходе. Который порождает странную задачу. Это как плыть против течения, вместо того, чтобы плыть по течению. Если требуется выполнить данную задачу, то лучше не побояться написать один дополнительный класс "Менеджер объектов", которому вы будите делегировать данную задачу. Чтобы поиск был быстрый, нужно использовать словарь. Время поиска будет O(1) против поиска в списке. Один из вариантов реализации может быть таким: В менеджере есть набор ваших списков (логические группы объектов) - список списков В менеджере есть словарь соответствия контрол -> индекс списка из (1) при добавлении контрола добавляете его в список и заносите контрол в словарь Поиск за О(1) Вариант, который предложил Kami хороший для вариантов, когда объекты ваши. А вот если вы хотите для штатных контролов это сделать, то чтобы подмешать такой интерфейс, вам потребуется сделать наследников для каждого UI контрола. А если эти контролы еще и на форме лежат, то там придется изрядно попотеть, чтобы добавить в IDE ваши версии штатных контролов с этим интерфейсом. P.S. Избегайте паттерна один контрол "владеется" несколькими списками. Это к "При создании каждого из них AOwnsObjects задано как True.". Такой подход рано или поздно при усложнии логики закончится AV и сложным дебаггингом, кто кого удалил и когда и почему. Используйте золотое правило: "Один объект может иметь только одного владельца, один объект может использовать во многих других местах. Только владелец отвечает удаление объекта и в хорошем случае и за его создание. Клиенты объекта только пользуются им и не удаляют его."
    2 балла
  3. Так поиск в словаре O(1). Вычисление хеша и получение индекса.
    1 балл
  4. Грех не написать подробный ответ нашему постоянному пользователю с времен зарождения форума
    1 балл
  5. krapotkin

    ListView - DynamicAppearance - header

    а если еще подумать, то это окажется то же самое )))
    1 балл
  6. Добрый вечер, Я подумаю об альтернативном средстве распространения новостей. Здесь отпишусь, как определюсь. Скорее всего буду публиковать новости на данном форуме в специальном разделе.
    1 балл
  7. В рантайме нет никаких дженериков. Компилятор преобразует все дженерики в реальные списки с необходимой типизацией. Поэтому - действительно никак. Вполне возможно, что даже is TObjectList<TMyClass> не сработает - компилятор вполне вправе посчитать исходный класс TObjectList<TMyClass> не тем, с которым производится is. Это неправильно. Потому что есть еще Insert, есть Update (в том числе - и InsertRange). Правильно - перекрыть метод Notify или реализовать обработчик события OnNotify (последнее даже создания наследников не требует). Вообще, если по каким-то причинам необходимо знать "владельца", было бы совсем хорошо сделать наследника от TRectangle, который будет реализовывать интерфейс наподобие такого: IOwneredIntf = interface ['{ADF563F3-B4CE-4E96-9559-F0FFC2936D5Z}'] function GetOwner: TObject; procedure SetOwner(const Value: TObject); property Owner: TObject read GetOwner write SetOwner; end; Список, который хочет установить владельческие отношения с этим TRectangle, в своем методе Notify приводит его к интерфейсу и устанавливает intf.Owner:=Self Ну и в обратном порядке - тоже. При этом появляется возможность работать со списком не только TRectangle, а вообще чем угодно, что поддерживает указанный интерфейс. И если список сделать тоже с поддержкой интерфейса (не знаю, какие методы в нем необходимы), то и сам объект может работать со своим владельцем абсолютно не интересуясь его типом.
    1 балл
Эта таблица лидеров рассчитана в Москва/GMT+03:00
×
×
  • Создать...