Вверх ↑
Ответов: 163
Рейтинг: 33
#1: 2015-02-15 17:22:23 ЛС | профиль | цитата
Netspirit, я там не зря вставил 2 проверки на null. Согласно документации,
public int onStartCommand (Intent intent, int flags, int startId)
...
intent The Intent supplied to startService(Intent), as given. This may be null if the service is being restarted after its process has gone away, and it had previously returned anything except START_STICKY_COMPATIBILITY.
Ну и сам Action часто может быть null, это необходимо учесть.

Netspirit писал(а):
нет необходимости создавать глобальную переменную с помощью AddVar()
Тут согласен, в данном случае можно было локальную переменную в функции объявить. Или завернуть что-то вроде
#hws
event(onStart, (ToType(',intent,' == null?"":(',intent,'.getAction() == null?"":',intent,'.getAction())), 2))
, но у меня от такого мозги плавятся :D
Netspirit писал(а):
Кроме того для данных типа int, String, double можно просто проставлять код точки в ini (1,2,7), тогда не будет необходимости использовать ToType при выдачи данных на точку.
Надо записать куда-нибудь, спасибо.

Netspirit писал(а):
По поводу ContentResolver. Что-то у тебя слишком много телодвижений. А что, нельзя в том месте, где он нужен, сделать
AddToImport('android.content.ContentResolver')
println('ContentResolver ', cr, ' = getApplicationContext().getContentResolver();')...
Оно то можно... Видно я после ассемблера больно придирчив к оптимизации стал Чего процессор по нескольку раз гонять прыжками по подпрограммам, если результат всегда одинаков будет? Для оптимизации под скорость лучше один раз прогнать, а потом только из переменной результат считывать. [flood]Вообще меня после асма джава до сих пор коробит Как-то не по себе мне от ее философии.[/flood]И кстати, в приведенном тобой виде можно делать только если это все в джава-коде будет обернуто в отдельный метод. Иначе поставим хаб на входе (разветвляющий) и подключим два его выхода к одному и тому же методу нашего элемента, и компилятор скажет о попытке дважды объявить одну и ту же переменную в одном методе. Тут либо делать cr глобальной переменной, либо везде по месту тыкать getApplicationContext().getContentResolver(). Вот, кстати, наглядный пример и повод задуматься:
#hws
Add(MainActivity,2953706,21,105)
{
Point(onResume)
link(onResume,16007637:doData,[])
}
Add(Display,5512927,245,126)
{
}
Add(Hub,15501647,182,133)
{
link(onEvent1,4767377:doWork2,[])
link(onEvent2,4767377:doWork3,[(214,146)])
}
Add(DoData,16007637,133,133)
{
Data=Integer(100)
link(onEventData,15501647:doEvent1,[])
}
Add(HubEx,4767377,210,133)
{
link(onEvent,5512927:doSetBrightness,[])
}
------------ Дoбавленo в 17.22:
В общем я это все к чему? Вот столкнулся я при написании элементов с проблемой как в последней приведенной схеме. И задумался, какие варианты?

  • Использовать в джава-коде только глобальные переменные.
  • Оборачивать код с локальными переменными в отдельный метод.
Сейчас я пользуюсь и тем и этим, но мне не нравились дубликаты одинаковых переменных и методов. Вот тогда я решил, пользуясь возможностями block.intext, создавать в коде на выходе эти переменные и методы-обертки лишь в одном экземпляре. И тут открывается еще более интересная возможность: эти вещи можно использовать в совершенно разных элементах (тот же ContentResolver может понадобиться разным по назначению элементам). Да, при написании элементов телодвижений больше, но в коде на выходе - наоборот меньше). И чем больше схема, тем это оправданней. Как-то так мне кажется
карма: 3

0