Entries tagged 'specification'

The saved setting block, as the name implies, simply saves a setting.
A very interesting block though. It allows you to locally store a single string value that you can re-use later on. Comparible with a cookie it can store a username (and password), but you can also store any value typed in by the user for search queries. On most mobile devices typing isn't the thing you want to do, so if the widget automatically stores the previous text it might come in handy for the next time.

1 <!-- The following code will save the text entered in a VisualTextBox to disk. The next time the widget is started, the textbox will still contain this value. The first time the widget is started, the text "Default" will be entered. -->
2 
3 <SavedSetting Name="savedtext" DefaultValue="Default" Input="textbox"/>
4 
5 <VisualPage>
6   <VisualContent>
7     <VisualTextBox Name="textbox" Input="savedtext"/>
8   </VisualContent>
9 </VisualPage>

The example here above is offcourse a simple way of implementing a saved setting. A more advanced developer might think of a way to have an unlimited amount(or atleast an amount that's not predefined) of stored values in 1 saved setting block. He/She might be able to do this by using a seperator and concatenating multiple values, another advanced user might not want to put a big load of data on a mobile device and he/she will only store a unique identifier on the device and link it to an online database. This could also be a way of recognizing your user as a developer and knowing your user could always come in handy. In other words, the saved setting block opens up a world of possibilities for your widget!

We have been listing a number of enhancements we want to add to the GLOWE specification.
Now we would like you to tell us what things can be better in GLOWE.
Just think, When you are creating a widget, what would help you add a functionality that would help your widget to be better, faster or less complicated?
When adding blocks to the GLOWE specification we carefully consider every possibility but there are a few criteria before we add blocks.
For example, No OS specific functionality. GLOWE is intended to run on multiple platforms.
Also Take in mind that the specification needs to be future proof. That means, no blocks that we might want to remove in the future
Remember the post "GLOWE with the flow" ? Any addition to the GLOWE specification should be as flow friendly as possible. ;-)

This is your chance to be part of the GLOWE future!
We're happy to hear your GLOWE specification comments. :-)