02-09-2012 10:27 PM
02-09-2012 11:32 PM
I don't see why you couldn't have an application that uses a PopupScreen.
I've written apps that "hide" in background and only push a modal popupscreen when they need user input.
02-10-2012 11:07 AM
02-10-2012 05:21 PM
I see. That isn't a widget though as it is on Android. The dev did a very nifty trick where he creates a wallpaper in the background and then displays that. It can update the wallpaper to show updates to stocks, weather, etc.
I wasn't entirly sure until I saw this: http://www.youtube.com/watch?v=z99aSASLqS4
When the app list fills the screen, you can still see the "widgets" in the background.
If you wanted to do something like this, it wouldn't be interactive (as previously stated), and probably wouldn't be that fast (never tried to see how fast the background could be changed).
Was there a perticular purpose you had in mind that required non-full screen, but not model dialog, apps?
02-10-2012 10:25 PM
If it is an modal dialog or show-through-background app, you will not be able to interact with BB home screen buttons. But I think this app actually allows you to click BB home screen buttons.
Here is one more:
02-10-2012 11:52 PM
02-11-2012 03:56 AM - edited 02-11-2012 03:59 AM
You could do a trick like take a screenshot, put up whatever you want over the homescreen, and when the user makes input you immediately close the popupscreen and pass the input through to the real homescreen. Meanwhile the "widgets" stay the same because they're replicated in the background. Then when the user is idle for a second you again take a screenshot and throw up a popupscreen the user doesn't even notice, because it's an exact copy of the homescreen. That would make for faster widget response.
Alternatively, you could potentially add your own widgets to the managers of the homescreen app itself; I haven't explored exactly what the manager & field heirarchy of the homescreen is, but you could do that in a simulator, and it is possible to get the references and potentially add your own fields to another app's managers, with field-change-listeners directed to your own app. But that would probably only work if they're basic managers like VerticalFieldManager, because you can't override sublayout for someone else's custom manager.