Screensaver?

Before going on with the discussion, you need to think about why you don't see screen savers for portable devices.


Screen savers on portable devices kill your battery life. You've been warned. [evil]



So assuming you want to continue, you need some way to start the app.

On the PC that generally means getting started by the system. I doubt that your cell phone will start your MIDlet after being idle a certain time.

If the system won't start it for you, you'll have to do it yourself -- find a way to hook into the system and monitor for idle time. Java does a good job of preventing that type of hooking. It is going to be phone specific and require some low-level programming, but I it can be done.


The other option is to have them manually start your app. It's not as fancy, but if you just want fancy graphics, it works well enough.


Once you find a way to have your app start, the app can be just a normal J2ME application. It just draws on the screen exactly the same way any graphical app would. You can draw images embedded in your app. You can draw gif images. You can compute and draw fractals. You can go look at the amazing computed scenes the demo scene people do with 4k and 64k applications.

That part isn't too hard.

Thanks for the reply Frob!

I understand the "cost" with screensavers and am willing to "pay the price" for testing =)

I'm looking into the low-level programming you mentioned, i'm guessing it is some sort of assembler?
Is there any information on how to start with this for cellphones? I'm either very bad at searching or there isn't much information about this...

You are correct, there isn't very much information on it. That's partly because they aren't designed to do it.

Remember that most (all?) cell phones only allow one MIDlet to run at a time. If you set a task to run "in the background" (meaning without a UI), it will still be the only MIDlet allowed. Running another MIDlet will (on most devices) ask the uesr if they want to stop the first process.

So anything out there monitoring for an idle system must be running outside of Java. Java's security model prevents you from breaking out of the sandbox, so you it will have to be a native application that runs in the background.

That means you'll probably have an app in C or C++.

Perhaps the particular cell phone will be running on SymbianOS. You'll need an application that targets that particular underlying system. Or maybe it's running on PalmOS, so you'll need something for that. Maybe it's running under any number of other systems. You'll need to either target them or gracefully tell them it can't be installed.

Those phone-specific programs might be able to wrest control of the display on demand, or they might need to hook into the system to do it. I'm guessing that since it will replace the active MIDlet, you will need to hook fairly deeply into the system using OS-provided commands.

The OS (probably) provides a way for a C or C++ app to intercept or interrupt the idle timer shutdown. That is another place where you'll want to hook.

Finally, when the user exits the screen saver, you'll want to gracefully return control to the other apps. That might require additional sysem hooks.

OS hooks aren't too hard to write in C++ for PalmOS, but I'm not sure about Symbian and the other OSs popular in today's cell phones. You'll have to check their docs.

I suppose I should mention it in case you don't know this already. It's becoming a bit of a lost art. [grin] I'll step through it one idea at a time.

An operating system hook is similar to an event listener, kinda sorta.

When something (an event) happens in the system, the OS calls its own function.

At the hardware level, they're called interrupts. In the software they are called OS hooks. (They have lots of other names such as software interrupts, OS Callbacks, interrupt events, OS signals, and so on, but the general vogue term today is OS Hook.)

When the event happens, the system runs the function. Depending on the implementation, it might work like an event listener where every listener gets called indepndantly. More often it is a chain where you replace what was there, then call the thing you replaced. Exactly how you get on that list is system dependant.

A simple example: Intercepting the mouse on Windows
You can create a mouse hook handler. It looks like a regular event hanlder, taking an id, and the normal WPARAM and LPARAM associated with mouse events. You register the hook by calling SetWindowsHookEx(). Whenever the mouse does something your function is called. You do whatever you want to process the event. When you are done you run the function CallNextHookEx() to pass it down the chain. In the case of a screen saver, you might use the function to just reset your timer and then pass the event on. Another use might be to reverse the flags for the right and left mouse buttons. Or maybe move the mouse cursor in the opposite direction from the motion.

Another example: The system is about to 'doze' on PalmOS
You can create an event handler. It looks like other event handlers on the platform. You call SysNotifyRegister() to tell the system you are interested in the event. In this case, we are interested in sysNotifyIdleTimeEvent. When the idle timer has expired, it calls all of the event handlers that registered to get the event. In this case, you would use it to reset the Idle timer (so it wouldn't doze), and tell the system to start your application if it isn't already running.


The biggest thing to know about these things is that they must be very quick and return almost immediately.

Imagine what would happen if every mouse move event took a millisecond: any time you drag the mouse around, the system would seem to slow to a crawl. However, if your command is very tiny and executes in just a few hundred or so instructions, you should be fine.

Any significant processing involved with hooks are usually done in conjunction with another process or thread. The hook sends an event to the other process and says "The thing just happened" and returns control to the OS. The other process can then do it's job without killing the system.

Because of the nature of this type of programming, it is very easy to crash the computer or make it a bit unstable. Subtle bugs in these things cause lots of computer crashes.

Well.. as a side-note: MIDP3.0 will support background-midlets! (Midlets running in the background!)

Thanks again for the replies guys! =)

Frob:
Ok, so there's no real assembler "program" you can write to hook system calls? The thing is i see there's not really many cellphones that run the Symbian OS and thus support C/C++. I was hoping i could do some sort of "hack" to tap into that "idle event" with either assembler or something similar, and make it work on the phones that do support screensavers, but don't run the Symbian OS.

I was also looking at the AMS MIDP Push Registry, to perhaps do a background timer myself. Ok, so it's ugly, but i also suspect it wont work any good because of the "only one active midlet" problem?

Pipo DeClown:
I wasn't even aware MIDP 3.0 existed (or will exixst). Do you have any more information about it, like when will it be released, will this be more of a "standard" than MIDP 2.0 was and what can you do with it? =)

http://www.jcp.org/en/jsr/detail?id=271 - all the info!

Dunno when they release it though.

Intresting reading...
I'm a bit curious to see if they'll make this "standard" a bit better than MIDP 2.0 (sound anyone?). After all, isn't the thought behind Java something like "write once, run everywhere"? ...and we all know how this works on cellphones. [grin]