сертификатом ты можешь подписать сколько угодно мидлетов в течении года.

подписанный мидлет имеет свои сроки годности и они обычно больше года (5, 10 лет)

сертификат не связан с определенным мидлетом

Да, т. к. пробуждение мидлета относится к пермишну javax.microedition.io.PushRegistry, а открытие серверного сокета - к пермишну javax.microedition.io.serversocket.


Если настройка установлена во "всегда спрашивать", то AMS должен верить ответу пользователя в отношении конкретного пермишна только до следующего обращения к этому пермишну. Т. е., например, если пользователь запретил мидлету открыть ServerSocket, то мидлет получит SecurityException, но при следующей попытке мидлета открыть ServerSocket - пользователя опять должны спросить.

Ещё вопрос по этой теме:

Если ставить временной вызов. Как я понял мидлет должен пробудиться в определённое время. Чтобы лбеспечить переодичность вызова, нужно после каждого вызова переустанавливать таймер.
Например.
* 10.00 (ставим таймер на 12)
* 12.00 (ставим на 14)
.....
А если произойдёт такая ситуация:
Таймер установлен на 10.00, но в это время мобила была вырублена. И по этой причине мидлет не был вызван, и поэтому не смог переустановить таймер на следующий вызов.
Думаю проблема понятна. Что здесь и как?

Ситуация с пользовательским изменением времени (системного) тоже интересна. Если таймер установле на 10.30, а пользователь в 10.00 изменит на час вперёд, тогда что? мидлет никогда не запустится?
Есть подозрение, что таумер запускает не ровно в 10.00, а в любое время после 10.00(если таймер не был вызван), те. запуск иден не при условии t==t_time, а при t>=t_time.
Тогда интересна другая ситуация: если 2 мидлета придётся запускать одновременно... получается, что первый запуститься и...тут же будет убит вторым мидлетом, так и не выполнив необходимую работу. Например не изменив таймер запуска последующего.

Похоже, что MIDP не покрывает этот случай, так что все остается на откуп конкретной реализации AMS. В той, с которой работал я, этот случай обрабатывался корректно - alarm push срабатывал сразу после включения телефона.


Вполне очевидно, если учесть, что t == t_time может не сработать из-за элементарных погрешностей и неидеальности режима реального времени  Другой вопрос, а дойдет ли вообще дело до этой проверки? Опять же, общего ответа на этот вопрос не вижу. В принципе, логично, что AMS, проснувшись после включения телефона, начинает сразу начинает прочесывать очереди зарегистрированных пушей и обрабатывать те, для которых пришло время, но это только общие соображения...


У убиваемого мидлета сработает destroyApp(), в котором можно проверить, был ли зарегистрирован следующий alarm или нет.

Всем спасибо. подсказок много, буду разбирать и решать.
А приложение - действительно будильник;)
Вот еще до кучи вопрос. Какими средствами организуется доступ к файловой системе телефона (карты памяти)?
( задуман выбор мелодии будильника из списка файлов телефона)