На чём писать под Андроид? (37 стр) / Программирование / Форум / Флейм / GameDev.ru

Barabus
C установкой СДК проблем никаких не было, и к Эклипсу претензий тоже особо нет. Но гугл к разработчикам мог и бы и получше отнестись. Ладно там, к мэйкфайлам и особенностям Эклипса привыкнуть можно, но вот отсутствие нормального дебаггера, и неработающие вещи в их же хедерах (например функцию showSoftInput у NativeActivity до сих пор не починили) как то напрягают.

Пользуюсь этой штукой, очень доволен =)

Эклипс - это жопа полная.
Андроид НДК - тоже полный звездец.

Но никто не сказал, что на этом нельзя программировать. Имея желание - программить можно на чём угодно. Тут большее значение имеет не конкретный СДК или ИДЕ, а что бы руки росли не прям между ягодиц.

Хотя, конечно, сказать что гугл сделал всё возможное для того, что бы упростить разработку под андроид - нельзя точно.

Между тем, со времен создания темы, кое что поменялось в плане отладки на эмуляторе (но хороший современный комп очень рекомендуется)... http://habrahabr.ru/company/intel/blog/146114/

dex
Спасибо, не слышал, попробую.

TarasB
> Да если бы х2 за вредность давали...

Не хочешь - не ешь. Прогай под красноглазых, шиндовс или иос.

Возможно, будет интересно, сегодня случайно выяснил, что вместе с релизом 20-ой версии плагина ADT для Eclipse, Google выпустил для него же NDK плагин для дебага нативного кода. Проверил - адекватно работает на эмуляторе и девайсе, почти без глюков. Вот ссылка с туториалом: http://tools.android.com/recent/usingthendkplugin

dex
> Пользуюсь этой штукой, очень доволен =)
Какая интересная штука. Как я понял, можно писать с использованием NDK прямо из студии, совершенно не задумываясь о том, как именно собирается дистрибутив, а также отлаживать на устройстве прямо из студии? Великолепно!

И за все удовольствие 79 баксов :)

Качаю триал.

Еще такой вариантец есть - http://www.opennet.ru/opennews/art.shtml?num=35272

Так, моя прога выдала ошибку "вызов Lock из разных потоков".
Но...
Я не использовал потоки.
Неужели каллбаки (то есть функции, указатели на которые я выставил в state->activity->callbacks) умеют вызываться, прерывая ход приложения на полуслове и не дожидаясь очереди?

TarasB
> Я не использовал потоки.

NativeActivity использует потоки. Оно буферизирует очередь команд от явы и передает их отдельному потоку где крутится уже С-шный код так что если сишный код "притормозит", это не вызовет подвисаний прокруток экрана и тому подобное. Как то так это обосновывалось. Тем не менее всё равно не очень понятно где могут возникнуть коллизии. М/б из-за того что код С у тебя вроде дергает код на яве... Хм...

=A=L=X=
Нет, я проверил. У меня вообще, судя по логам, вызвались по очереди события А,Б,/А,/Б. Хотя А и /А находятся рядом в одном блоке (выходов посередине нету), а Б и /Б - в другом.
БЛИИИИИИН КРЕТИНЫ ИЗ ГУГЛАААА Я ВАС НЕНАВИЖУУУУУУ

Между прочим, винда себе такого не позволяет, сообщения всегда сидят в очереди.

TarasB
> У меня вообще, судя по логам, вызвались по очереди события А,Б,/А,/Б.

Да, это странно, по идее не должно быть такого.

=A=L=X=
Короче эти долбанные калобаки вызываются в отдельном потоке, вот так-то ВЕСЕЛО ЖИТЬ!!!!

Я сделал так:

  volatile bool inEHR=false;

  void EngineHandleResized (ANativeActivity *a, const ARect *r)
  {
    LOGI("EngineHandleResized to (%d, %d)", newBufSizeX, newBufSizeY);
    inEHR = true;
    newBufSizeX = r->right - r->left;
    newBufSizeY = r->bottom - r->top;
    inEHR = false;
    LOGI("/EngineHandleResized");
  }

А внутри главного цикла проверяется, что если был вызов этой функции, то только тогда послать сообщение в главном потоке

while (inEHR);

    if (bufSizeX != newBufSizeX || bufSizeY != newBufSizeY)
    {
      LOGI("resize window, locked = %d", locked);
      if (!locked)
      {
        // на самом деле окно может поменять размер и тогда, когда буфер блокирован, 
        // ведь некоторые мои проги рисуют картинку в несколько этапов, отвлекаясь на приём сообщений
        // так вот, информацию о размере буфера обнвляем только если буфер не блокирован. 
        // Если он блокирован, то там в функции разблокировки тоже есть проверка, 
        // что если размер поменялся, то надо обновить состояние

        bufSizeX = newBufSizeX;
        bufSizeY = newBufSizeY;
      }
      if (!TbalMain(ACTION_MOVE, CODE_RESIZE, newBufSizeX, newBufSizeY))
      {
        active  = false;
        running = false;
      }
      LOGI("/resize window, locked = %d", locked);
    }

Теперь вопрос: я НИКОГДА, понимаете, никогда вообще не писал многопоточный код ибо нахрен мне оно не усралось. Так вот, как по-научному написать фрагмент

while (inEHR);

ожидающий когда второй поток выйдет из задовызова?
Мне что, надо подключать какой-то там boost::threads::sections::critical_section?
Или в таком виде код тоже рабочий?

TarasB
> Так вот, как по-научному написать фрагмент

pthread либа есть в NDK, так что по правильному и простому - через неё. Типа локи какие то это называется, я сто лет не притрагивался, код не подскажу. Погугли.