I've recently been reading up on and testing different values for the following registry key :-
HKLM\System\StorageManager\FATFS\CacheSize
By default in Tuma 1.3 this key is set to 4096, which agrees nicely with the maximum value in the following MS document on FATFS registry keys.
http://msdn.microsoft.com/library/d...tml/wce50confatfilesystemregistrysettings.asp
Having read this I decided to try some higher power-of-2 values to see if 4096 really was a hard limit on cachesize. To my surprise, setting a value of 32768 does work, and shows an increase in memory use after boot. (~37mb with 32768 cachesize, versus ~23mb with 4096 cachesize)
NOTE The next highest power-of-2 (65536) caused corruption of the today screen, so that should obviously be avoided.
Does anyone know if the extra space is likely to be actually used as cache? Or does this just allocate memory that is never used?
My Qtek 9090 does seem to respond faster, once the cache is loaded with recent apps, but I also know it's easy to delude youself that such "tweaks" are having a real effect.
Could someone else confirm this for me?
Obvious disclaimer - don't edit your registry if you're worried about turning your phone into a useless hunk of plastic.
thingonaspring said:
I've recently been reading up on and testing different values for the following registry key :-
HKLM\System\StorageManager\FATFS\CacheSize
By default in Tuma 1.3 this key is set to 4096, which agrees nicely ...
Click to expand...
Click to collapse
Yes, this is delibrately done to not 'push the device into undocumented territory.
Does anyone know if the extra space is likely to be actually used as cache? Or does this just allocate memory that is never used?
Click to expand...
Click to collapse
The extra space is allocated, and it would be used - albeit rather slowly:
4096 = 2Mb, 8192 = 4Mb, 16384 = 8Mb, 32768 = 16Mb cache size. Applications (and data) need to fill this space to make it useful. Also, it's proven by your memory change from 23Mb to 37Mb = 14Mb ... exactly the difference between 16Mb and 2Mb (by coincidence? ;-))
Using more than 2Mb of cache space will in the short term possibly make your device run faster, however when the compaction thread needs to run (and stuff needs to get written back to flash), it will attempt to buffer as much as possible, and then take it's time while it 'locks up your device' and flushes 16Mb (possible) of data ... instead of 2Mb. Multiple smaller blocks will have less impact on the usability of the device - so there's been a careful balance done between performance and continuous usability. Sure you could make it faster in the short term ... but long term you'll hit those 10 second pauses.
In testing I've found 2Mb to be a good upper limit. Try 4Mb if you've got a lot of data intensive applications, but otherwise I can't see too much benefit in going larger. Also - the chance of losing something is greater ... a reset while things haven't been written to flash, and *poof* it's gone.
Excellent info Tuatara, that explains a lot about why my device was running in stops-and-starts ;-)
This is very interesting. I own a hx4700 device and rescently upgraded it to wm 5.0 (the nightmare begun). The information I found here is totaly oposite of what some wise heads are suggesting on other forums.. and this works. Lowering the cache (setting DataCacheSize to 0x100) made my device more responsitive when compaction runs (20 minutes every few hours!)
I have few questions about the compaction thread - Is the compaction process always taking constant time (depending on the size of the files on the device)?
Compaction always takes long time to finish - about 20-25 minutes on a 35megs free flash. Is this normal ? Block size of the flash reported by some hp utility is 128kb, in registry (and bootloader after lnb) shows 256kb. Could someone explain the exact logic of the compaction thread ?
I have another question - the msdn mentions that CacheSize is deprecated and should the folowing keys be used: FatCacheSize and DataCacheSize. Why are you still using the old reg key ?
If the compaction problem is solved in the hx4700 (and probably on the dell x50v) the device will be worth it's money.
Thank you for the great forums and the great community.
Performance ... what matters? The 'NOW', or the 'ALWAYS'?
orcish said:
This is very interesting. I own a hx4700 device and rescently upgraded it to wm 5.0 (the nightmare begun). The information I found here is totaly oposite of what some wise heads are suggesting on other forums.. and this works. Lowering the cache (setting DataCacheSize to 0x100) made my device more responsitive when compaction runs (20 minutes every few hours!)
Click to expand...
Click to collapse
It's a trade-off really. The total time required for the compaction is still going to be the same. For example, using up blocks of the flash memory is going to 'fragment' the space. When you need that space, the issue is: 'is it ALREADY available'?
By running the thread more often (to clear unused blocks back to being available), your device 'continuous over time' performance increases, but by doing the compaction 'all at once' your device's 'instantaenous performance' is higher.
Rant on.
Benchmarks love the latter ... users (should) love the former.
This is why in the new TuMa v1.4 ROM I'm working on, I've gone AGAINST all of the other 'benchmarks' and dumb short-term tweaks and so-called solutions, and looked at device performance overall, and over a long period of time. Performance is now 'managed' rather than 'peaked', so that things are kept at a good rate of continuous usage, rather than trying to maximize an instantaneous time. Benchmarks really should measure the device in two weeks of use ... not right after it's configured.
What good is a fast device right now, if in one weeks it's slow as mud all the time? Yes, the TuMa v1.3 is slowing down - but the degree of slowdown of that ROM isn't to the point of 'unusable' as is the case with some other WM5 versions (for very well known reasons now). Knowledge is always gained, and improvements are always made with enough time and patience.
This is the other point I raised for people trying out the "new ROMs" ... (which in truth haven't addressed ANY performance concerns when you look at the changes done). These "latest and greatest", "just released", "new and improved", and "better and faster than ever" - ROM release adopter junkies are just experiencing "new device syndrome". Of course it'll be faster - DUH - you've just given it a clean slate to start from! Your multi-week old device has just been cleaned of it's junk, and it WILL be so much faster with the new ROM. REGARDLESS. Shyeah ... think about it.
Sorry ... rant off.
I have few questions about the compaction thread - Is the compaction process always taking constant time (depending on the size of the files on the device)?
Click to expand...
Click to collapse
The time it takes is effectively a constant. It must erase the blocks of Flash, and organize the filesystem based on this. Erasing is slow ... which is why when it 'piles up' and there's a lot of work to do, the compaction thread really can't finish and return control to the device, until it's done the job. It's akin to stopping a defragment of your hard drive ... sure, some of it is clean & organized, but the remainder is still a disaster. Update that drive in the meantime, and it needs to start all over again.
Compaction always takes long time to finish - about 20-25 minutes on a 35megs free flash. Is this normal ? Block size of the flash reported by some hp utility is 128kb, in registry (and bootloader after lnb) shows 256kb. Could someone explain the exact logic of the compaction thread?
Click to expand...
Click to collapse
A lot of questions ...
1). 20-25 minutes is FAR too slow. There is definately something else taking up 'residence' or CPU time during this process. It sounds like you have an application installed, or a device driver, or you've twiddled priorities improperly, incorrectly using temporary storage, resulting in over-use of your flash. A hard-reset and careful re-installation of your applications MAY be warranted to fix this. *more below*
2). Block size is quite probably 256Kb. I think your device also uses the M-Systems DOC 64MB chips.
The DOC G3 64MB (512Mb) consists of two 32MB (256Mb) flash planes that consist of 1024 blocks each, organized in 64 pages, as follows:
Page (Storage Unit) – Each page contains 512 bytes of user data and a 16-byte extra area that is used to store flash management and EDC/ECC signature data. This is the SIZE of block which changes EACH TIME something gets saved to memory on your device.
Block (Erase Unit) – Each block contains 64 pages (total of 256Kb). A block is the minimal unit that can be erased, and is sometimes referred to as an erase block. This is the SIZE of block which must BE ERASED each time we need some more space on the device.
Note: Since the device works with multiple planes, the operational block size is actually 512Kb. This means each time 64KB of space needs to be erased, when a block can bee freed.
3). And now the hard question ...
The compaction thread is effectively attempting to move the random fragmented blocks of 512 bytes of data in each of the Storage Units around into larger blocks of 32KB (256Kb) Erase Units. Otherwise, you'd have parts of your data erased each time you needed more free space in the Flash to use. 8)
Essentially this comes down to a "defragmentation" algorithm, however the problem is that the device is still actively being used at the same time. To solve this obvious problem - the device NEEDS to be paused, the compaction run to completion, blocks are freed up for usage, and then the job can continue. It's quite obvious when you think about it.
For example ... 64 Erase Units, each has 1 Storage Unit usefully allocated in it. The compaction thread now can in theory take each of those 64 Storage Units and put them into one larger 'Erase Unit' Block space. To do this is needs to read ALL 64 units (32KB) into memory, maintain all the blocks UNFREED (since if you reset your device now you'd lose your data). Erase a new UNUSED Erase Unit, write all 64 Block Units into the new Erase unit. Then it can go through and mark in the FileSystem, where the NEW location of these Storage Units is. Once that's done, it can mark those other 64 Storage Units as being available for Erasure (or for reuse of any remaining Storage Units within it). If it detects that they are full, then those 64 Erase Units can be erased, and it goes ahead and does that. Natually all this 'shuffling' of data, with guarantees that you don't lose any in the process, needs to be done CAREFULLY and PROPERLY.
*RANT* ... For (insert deity of choice here) sake ... NEVER EVER HIT THE RESET PIN WHILE YOUR DEVICE IS BUSY COMPACTING!!! You can (and probably will!) lose your data ... have patience ... just wait ... it really is busy doing something VERY important. But otherwise, go ahead ... RESET away ... you'll probably be cursing that you're continually doing HARD-RESETs all the time, and that it's a sh*tty device you've bought. Well ... after all ... you NOW KNOW ... it really IS your OWN fault. :roll:
The issue comes when there is something which CAN'T be paused (a device driver, OS core, etc.). This will still need flash storage space while the compaction thread runs. This is possibly why your compaction takes 20 minutes or more. Remove the 'extra stuff' which could be doing bad things.
Also, there are those (I shouldn't use the word, but anyways) idiotic people who think that by forcing this to the "now" that they're making their devices better. For example - inapprorpiate use of Priority256 registry keys, in raising the priority of a task (to above real-time even!) in order to solve their immediate issue - they believe is a good thing!!??!!
This results in the compaction thread needing to 'back off', then the OS runs the 'real time task' which corrupts the defragmentation process, so when the compaction thread has an 'idle' chance again, it starts up ... starts cleaning ... tries ... gets interrupted ... (cycle repeats).
I'm trying to 'do away' entirely with this issue in TuMa v1.4 by forcing the compaction thread to run more often, at times when it can do so, just below application level requirements, but above idle. So barring any 'fixes' introduced by l-users ... it should maintain an even performance level over time - barring obvious issues, like when the Flash is too full for compaction to run!
In this way, through usage testing by knowledgable users, I have validated 'theory' in Alpha versions, and will now/shortly be moving into 'practice' in Beta testing with a lot more 'general' users becoming my 'unwitting' performance testers in releasing the TuMa v1.4 ROM. I believe theory will be put into practice, and as experienced by the alpha testers, performance should be continuous and stable. 8).
I have another question - the msdn mentions that CacheSize is deprecated and should the folowing keys be used: FatCacheSize and DataCacheSize. Why are you still using the old reg key ?
Click to expand...
Click to collapse
CacheSize is deprecated, and in TuMa v1.4 ALL keys are explicitly specifed, while in TuMa v1.3 FatCacheSize was not. The reason is two-fold. For the BA ROM (since it's unofficial and a patchwork of other ROMs), these ROMs were still using older drivers (WM2003SE) which did not support the new keys.
The explicit 'new' keys override the deprecated key. However, the old key is still kept in there for legacy reasons, or for applications or users who might 'insist' on twiddling them in the future. I'm now resorting to this, and trying to 'protect' people from their own performance tweaking "foibles".
If the compaction problem is solved in the hx4700 (and probably on the dell x50v) the device will be worth it's money.
Click to expand...
Click to collapse
If people are willing to put up with a slightly slower 'overall' device, but have continuous same-level performance ... then I can give them an answer (hopefully) right now, or soon if I ever get this TuMa BA ROM to a point I'm happy with it (probably AKU2).
If they want to be blind adrenaline junkies and need 'speed at any cost' ... just keep doing what they're doing, tweak caches, put off until later all the housekeeping, and then, when it hits the wall, go ahead and try to do it all in 20 minutes of device lockup when it's become all too much to handle.
If they want 'rocket-ship' speeds at all times, they'd better carry around a non-flash based device or a laptop. But they'll look REALLY dumb holding up one of those things to their ear when making a phone call. 8)
[flame retardant suit is on]
Thank you for the great forums and the great community.
Click to expand...
Click to collapse
Thanks for such a great set of questions ... let's me get the point out as well.
Now ... I wonder who else will actually read this post? Maybe it'll be Wiki'd? Maybe ... maybe it's better if not.
Whao! A reply beyond my expectations! Thank you!
Here is my questions:
Update that drive in the meantime, and it needs to start all over again.
Click to expand...
Click to collapse
Is this about the compaction thread or the disk defragmentation process? If it's about the compaction thread - probaly seting the Prio256 and PrioCrit256 to real time would make it almost interruptable (and make the device freeze for some time). If running time with critical priority takes effectivly less than my usual 20 minutes, it means that something is messing my compaction, right ?
1). 20-25 minutes is FAR too slow. There is definately something else taking up 'residence' or CPU time during this process. It sounds like you have an application installed, or a device driver, or you've twiddled priorities improperly, incorrectly using temporary storage, resulting in over-use of your flash. A hard-reset and careful re-installation of your applications MAY be warranted to fix this. *more below*
Click to expand...
Click to collapse
I'm not fiddling with the priorities, and have no running applications (except acbPowerMeter or/and SuperTask to monitor the activity). When compaction hits I just close everything and watch it complete. When acbPowerMeter reports about 380mA usage - it's the Compaction. filesys takes about 90% cpu (10% taken by the SuperTask when it refreshes the screen with new readings). Activesync is stopped, disabled and etc.
Is it possible to monitor disk .. err.. flash activity ? All read/write calls? Probably a filesystem filter? (about filesystem filters I have a question below)
Is it possible to take some information about the compaction process itself, % done, blocks freed and etc. I suspect that there is something wrong - probably trying to compact a bad block or something like this. I have seen people complaining about this in the platformbuilder newsgroup.
Something that may be conneted to this issue is the filesystem filters I found attached to my storage devices. I have fsdspy and fsreplxflt. What are they? Some information points that fsreplxflt is for replicating ram to rom and fsdspy as an example!? Are they needed actualy?
Thank you for your reply, I have more questions and when I clear them in my head, I'll be more than happy to ask them to you.
Hi Tuatara,
Great explanation - clears up a few questions I had.
One question, however, remains. What's the easiest way to tell your device is compacting and hasn't just hung? I've had a few times when my device seemed to just hang solid - nothing worked, no buttons, no touchscreen, nothing. So I soft reset the device to bring it back up with no data loss. I assume this was a crash not a compaction.
Is there any way in TuMa 1.4 that you could make a "Compacting" icon or similar so that we can tell when compaction is being undertaken?
orcish said:
Whao! A reply beyond my expectations! Thank you!
Click to expand...
Click to collapse
Well I aim to please ... or was that ... I'm pleased to aim ... *fire* ... eh ... whatever. ;-)
orcish said:
Update that drive in the meantime, and it needs to start all over again.
Click to expand...
Click to collapse
Is this about the compaction thread or the disk defragmentation process?
Click to expand...
Click to collapse
In the simplest terms for our devices it's both. Disk defragmentation is just the example everyone understands ... so I'm using this 'understanding' to explain it.
A flash disk doesn't need ANY defragmentation - it's indexed like RAM, and we can get at any data directly. No need to make any data contiguous like on a hard disk (which spins). So, that's why they use the word "compaction" instead of "defragmentation" ... but the principle is the same.
So ... putting it simply:
It really doesn't matter where it's stored to ACCESS it. But it does matter where it's stored if we need to ERASE it.
Remember we have 64 Storage Units per Erase Unit. This means that if we are actively using even one of those Storage Units, but need to erase the rest of the block to get more "free" space, we need to move the used Storage Unit somewhere else first, before we can erase that block, to use it again.
If you have an application writing to storage during this time ... well ... then the 'free' Storage Units in those nice-new-empty Erase Units can be used up, and the compaction thread has to start over again - trying to pack things in to make more available free space.
orcish said:
If it's about the compaction thread - probaly seting the Prio256 and PrioCrit256 to real time would make it almost interruptable (and make the device freeze for some time). If running time with critical priority takes effectivly less than my usual 20 minutes, it means that something is messing my compaction, right ?
Click to expand...
Click to collapse
Yes ... that would be true - although I have no idea what running the compaction thread at time critical would do to your device!!! I would probably set it to a NORMAL (0xfb / 251) priority ... maybe something at most "THREAD_PRIORITY_ABOVE_NORMAL" (or 0xfa / 250) at a highest value. It may be worthwhile to experiment and see what the result is. Backup your device before doing this though!
orcish said:
I'm not fiddling with the priorities, and have no running applications (except acbPowerMeter or/and SuperTask to monitor the activity). When compaction hits I just close everything and watch it complete. When acbPowerMeter reports about 380mA usage - it's the Compaction. filesys takes about 90% cpu (10% taken by the SuperTask when it refreshes the screen with new readings). Activesync is stopped, disabled and etc.
Click to expand...
Click to collapse
I can't answer this one unfortunately ... there are so many intricate details in the OS which could have an effect. Experiment with the priority settings if you wish to ... might be an option to see what the real cause is. If the compaction happens quicker, then we know it's due to flash usage collisions.
Thinking about it - change only the CritPrio256 values ... i.e. when the "s*it really has hit the fan" do it or else ... and see if it completes in less time. If you don't hit critical compaction - then try setting the standard priority as well.
orcish said:
Is it possible to monitor disk .. err.. flash activity ? All read/write calls? Probably a filesystem filter? (about filesystem filters I have a question below)
Click to expand...
Click to collapse
It would be possible - I think that mamaich may have written such a tool for himself, but it is just that - a tool, and not something which could (or should) be actively utilised.
orcish said:
Is it possible to take some information about the compaction process itself, % done, blocks freed and etc. I suspect that there is something wrong - probably trying to compact a bad block or something like this. I have seen people complaining about this in the platformbuilder newsgroup.
Click to expand...
Click to collapse
I'm not sure if this is possible ... part of the problem is - where would you put the result data? It would need to be a memory mapped file or something, which is locked exclusively in RAM, so as to not touch the flash, and then your reporting app would need to operate in a similar manner. Not sure ... maybe there is a way to get some info (from the TrueFFS driver) but I wouldn't know how to.
Along the "bad block" concept - the TrueFFS driver has management within itself to control bad blocks and to transparently reassign blocks which have been deemed 'bad'. It is possible that this logic is somehow failing - i.e. not working as advertised.
You could try changing the Read/Write and Verify methodology which the TrueFFS driver uses. Here are some registry entries which might help you track down the problem. You should have registry entries similar to:
Code:
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\TrueFFS???]
“VerifyWrite”: When using this parameter, TrueFFS performs an immediate read operation
from the flash after every write cycle.
The value of this entry can be as follows:
dword:0 - Sets TrueFFS to Optimized Verify Write mode. This is the default TrueFFS mode for
devices supported by INFTL, such as DiskOnChip Millennium Plus and Mobile DiskOnChip. In
this mode, a sector is assumed to remain valid after it has been verified as long as no sudden
power-down event occurs; therefore, no additional read operations (verifications) are performed.
When recovering from a power failure, TrueFFS gradually verifies the validity of additional
sectors as data is written to the disk partition. All the sectors on the disk are eventually verified,
at which point no further verification is done and peak performance is achieved (default).
dword:1 - Sets TrueFFS to Read Before and After Write mode. In this mode, each write
operation is preceded by a read operation verifying the flash area is indeed erased, and followed
by a read operation verifying the data was written properly. Only after both conditions are met is
the sector considered to be written properly. Selecting this option results in lower write
performance, but insures absolute data protection against power failures or any other event (such
as errors caused from noisy buses, faulty flash, or flash close to its end of life).
dword:2 - Sets TrueFFS to Standard mode. In this mode, a sector is considered written
successfully when the flash media reports that the write operation ended successfully. Additional
verification (using a read operation) is not performed, so TrueFFS works at peak performance
regardless of past power failure events. This is the default mode for devices supported by NFTL,
as these devices do not require additional verification for most applications.
“UseCache”: Enabling this option improves performance, but requires additional RAM
resources. The NAND Flash Translation Layer (NFTL, INFTL or SAFTL) uses a small part of
each flash unit and sector for control information that allows accessing the data stored on
DiskOnChip as a virtual block device. Setting this option to 1 enables caching this information in
order to improve performance.
dword:0
dword:1 (default)
“RemoveFatFilter”: The Windows CE TrueFFS driver contains a FAT filter that monitors file
system write operations to the FAT area. The TrueFFS driver uses this information to improve
performance by deleting sectors from the media when the corresponding file is deleted. Use this
entry to disable FAT filter operation.
dword:1
So I'd try “VerifyWrite” = 1, “UseCache” = 0, and leave the FatFilter enabled ... see if this helps 'eliminate' that possible bad block issue.
orcish said:
Something that may be conneted to this issue is the filesystem filters I found attached to my storage devices. I have fsdspy and fsreplxflt. What are they? Some information points that fsreplxflt is for replicating ram to rom and fsdspy as an example!? Are they needed actualy?
Click to expand...
Click to collapse
The fsdspy filter is used to monitor the filesystem - incl OS level and TrueFFS driver performance checking (and for hooking). For the fsreplxfilt filter I believe this is required for data replication ... but the inner details of what it does, I'm not sure either. You do need to specify WHICH directories and files are NOT included - so therefore I believe it to control which files should NOT be replicated to the Flash as soon as possible (i.e. they are maintained in RAM cache, and only flushed at a later date, or by a special seperate thread - things like the registry files, temp files, object store, etc.).
orcish said:
Thank you for your reply, I have more questions and when I clear them in my head, I'll be more than happy to ask them to you.
Click to expand...
Click to collapse
Heh ... I'll just need to find more time to answer then!
HiltonT said:
Great explanation - clears up a few questions I had.
Click to expand...
Click to collapse
You're welcome ... it's always better when things are 'demystified'.
HiltonT said:
One question, however, remains. What's the easiest way to tell your device is compacting and hasn't just hung? I've had a few times when my device seemed to just hang solid - nothing worked, no buttons, no touchscreen, nothing. So I soft reset the device to bring it back up with no data loss. I assume this was a crash not a compaction.
Click to expand...
Click to collapse
Compaction runs at a lower priority than other tasks, so if you have NO response from it for 10 - 20 seconds ... especially wait longer after having been IDLE for a while ... then it has definately crashed. Just give it enough time to see if it will recover though ... large block erases can take time - especially when the filesystem is in a 'transitional' state.
HiltonT said:
Is there any way in TuMa 1.4 that you could make a "Compacting" icon or similar so that we can tell when compaction is being undertaken?
Click to expand...
Click to collapse
We could have a 'task manager' which monitors the process list and then puts up a 'red light' when the CPU is being used for this task ... it may be a worthwhile project for someone to undertake. Unfortunately I don't know of anything like this at present ...
Tuatara said:
orcish said:
Talking about Compaction, Priority, and setting registry entries ...
Click to expand...
Click to collapse
And I made some recommendations to try ...
Click to expand...
Click to collapse
I was just re-reading things from Mike (http://blogs.msdn.com/windowsmobile/archive/2006/03/16/552996.aspx) and realized that no matter what you do to those Priority registry keys, they will have no effect. *sigh*
I'm changing those keys in the boot.hv (XIP section) in TuMa ROMs, so I do have the ability to change those priorities directly, but this is not an end-user Registry thing.
If I get the time, I may look into the 4700 ROMs and see if there is anything which can be corrected/adjusted for these - either that, or someone who can modify these ROMs is welcome to PM me, and I can send them the full registry dump (boot.rgu) and they can attempt to merge in the settings themselves and see how that goes.
Again ... apologies, but it appears MSoft has decided that you're not permitted to mess with these settings. The TrueFFS registry settings may follow the same rule, but then again - I'm not entirely certain of this.
I've tried my best to search the forums for this topic, either there really aren't any topics regarding this, or I'm just really incompetent!
Well as the title suggests, I'm looking for a web filtering/content monitoring application that will filter out inappropriate sites browsed on my Kaiser. You can never be safe on the net, especially with kids advancing at such a scary rate. Been searching the net (google) for something made for windows mobile, but zilch. I've also been looking for something that could possibly filter the entire network, but it's usually one of those that you need to install on each machine, which still doesn't address the problem.
Any help will be appreciated, or maybe this is something to think about for your next app!
Cheers
Never used these myself but here's a few links to get you started:
http://handheld.softpedia.com/get/Security/Utilities/SMobile-Security-Shield-Parental-Controls-Edition--Windows-Mobile--77635.shtml
http://free-parental-control-filter.parentaltools-net.qarchive.org/
i can't suggest something for your exact requirements at the moment...
i was thinking, though, that you could set up your device to prompt for a PIN (known only to you) before unlocking the screen for general use. of course, this suggestion is meaningless for you if you want to let your kids use the phone (play games, etc) but still control the content viewed in browsers...
Hi !
I'm new to this forum, and a new user of Android (2.1) / SGS. I recently switched from the iphone 3G, which was ****ed up by ios4 and after swearing I'd never buy another crapple product ever again.
As a linux user / open source fan, I love my SGS so far. I've started messing around with a number of things already, mostly basic customization and application / widget picking, and have landed on a launcherpro+folderorganizer setup. Now enough about my life nobody cares about, I have a few noob questions that are yet unanswered by my initial research, thanks to anyone who will take the time to answer !
1) Regarding plugnplay'ness : when I plugged my SGS to my computer (win7), at first it wasn't recognized. I had to google the error, find some samsung drivers, install them (took a while) before I could access the phone in explorer mode. Is that normal behaviour ? I kinda hoped the phone would be recognized as a "usb key" on any computer without having to install anything.
2) For Android updates : from what I understand, the way of doing them is to install Samsung Kies on a PC and pilot the upgrade from there, correct ? Or is this only for major updates ? Is there a way to auto-update the OS from the phone itself without needing to use Kies ? Are there other things I can only do with Kies (without needing extensive knowledge of Android internals) ?
3) About root : apart from installing android versions that are not yet official, what are the common uses that require root privileges ? I'm familiar with what being root means under linux, but I guess my question would be more like : what are the restrictions on the default user and what do they prevent him to do ?
4) The "lag" : I see everywhere mention of this "lag" problem. I haven't noticed any. Granted, I come from a world where simply opening an application can take anywhere between 15s (iphone 3G+ios4) to 10s (iphone 3G+ios4.1), so maybe I just got used to things being slow ? Or is this happenning only on some specific devices / setups ?
5) The keyboard : is there a way to hand-pick the keyboard layout ? I have my locale set to english because I like the english OS interface better, I have my input language set to french because that's the language I write most in, which results in an azerty keyboard layout which sucks. I'd like to hand-pick the swiss keyboard layout (qwertz with accents), I know it exists because it switches to it if I pick german as input language, anyway to do that ?
6) Android market and security : is there any control from Google over if not the quality, at least the security of apps in the market, or not at all ? Is it my duty as a user to make sure that any app I would download from the market is "safe" ? Is there any justification for installing something such as an anti-virus on android ?
7) MarketS : there are other markets than the "default one" out there. I do not understand their sales pitch. Aren't applications that are in other markets also in the Android Market anyway ? Where is their added value ?
8) Taking notes. On the iphone I loved the iconic notes application. It allows to create a hierarchy of folders and subfolders and write/store notes inthere. I haven't been able to find anything similar yet, the market seems spammed with forks from an "hello world" notes application. Any recommendations ?
9) RSS : I haven't been able to find a good RSS reader as well. By good I mean feed categories, widget, and support for images. Any recommendations for this ?
10) Media files : it seems that the embedded applications that aim at reading media files (images / music / video) auto-scan the folders on the SD card for supported file types and include them. Is there any way to prevent this on some folders ? For instance I used ringdroid to create a few ringtones, but now those appear in my music player, so I'd like to prevent my ringtones folder from being used by the music player.
11) GPS : haven't played with it much yet, but I read here and there it was buggy. Is it a general state or country-specific ? On an unrelated note, are there offline maps navigation applications available ?
Well 11 questions is probably enough to start with. If you take the time to answer, I thank you in advance .
You do not find anything, Why :?? Rss channel is on all sides, until you can organize its yourself ... kies works for the exchanges,multimedia mp3, video.. the last Firmware is recognize the kies,but need the driver , firmware changes are another thing, I had the iphone 4 .safari browser ****, really slow and messy Iphone 3gs is more better.I sold that **** 250 pound When The prize is more 400 pound, crap, The iphone 4 his value is U.S. $ 200. If you feel good in Iphone buy one and play with him .. ahh and have problems with sound and audio capture .. And not just for me, the number of comment are no good to Iphone 4. My SgS 9000 Working 100% kies Working Good, Video , No lag , Browser,,Everything. if something is wrong there you need chekin out, My Firmware is JPM, And The Market have everything, Everything Working in my SGS , Regards
So I recently got very interested in Windows Phone 7 (mango) and I had been thinking about starting to create my own apps for a while. The result is the idea for an app that is as follows:
Name: Crumbs
Possible abbreviation: to send somebody a "crumb"
In short: An app that capable of: writing/creating, organising, sharing and following instructions, AKA crumbs.
What I want to achieve with this is a new option into social networking, but this time it's also very useful and not just fun to show off. What could these crumbs be? Well, I've thought of some categories already:
Routinely task:
like the stuff you do every morning, shouldn't forget, etc.
Work/study task:
some sort of study schedule, with certain points you should handle to complete the whole task.
Preparation/cooking task:
doesn't need any explanation.
Scavenger hunt/adventure:
wouldn't it be great if you can give a list of instructions to someone with some reward at the end?
Travelling:
similar to your adventure, but could contain various flight data or a couple of options (so you don't "finish" an item, but finish 1 item in a dillema.
Other: always have some other category..
User defined: if a user wants to make his/her own category.So these are the categories, but as you've already seen, each category has different types of commands/operations one has to perform to complete the whole task. So when writing a new one, you could filter the entry-options by the ones most important for that category and give the users a seperate option to add another operation than the ones listed by default. Some possible operations and their integration ideas are as stated below:
Action: very straightforward, do something and when executing the crumb you simply check the box when done. Maybe some option with a timer that alerts you that you should be done with the operation soon (for example: cooking).
Navigate: go to a specific location and then you check the operation. Possible GPS integration/maps?
Input: give certain input to go on. For example useful when creating an adventure (go there, look for the church and read what's on it) or something else that should need a password or any other input.
Alert: to alert yourself/the executor OR (and this is important) some other user that you've arrived at a certain operation in your crumb.
Yeah, you read it right, another user. Because one other important aspect of almost every app nowadays is SHARING. So ofcourse, there will have to be the option to share crumbs. People will be able to manage their crumbs on a phone ofcourse, but if there's a lot, wouldn't it be easy to have them stored online too? A place where you can rapidly type, organise and share your crumbs. So there should be a format to save them in (.crumb looks fantastic ). So, you simply send someone the crumb using a public link you create for your privately stored crumb. But what about something called instructors/friends? Wouldn't it be awesome if you can allow certain people to GIVE you crumbs straightaway, so you'll get alerted and know you have to do something (OK, "your mom" wouldn't be awesome, but useful nonetheless). To make things easier for this, the users will have to be able to manage these friends/instructors too and have their own cookie jar/cake box to receive their crumbs directly in (on the website and in the app). I sense some Facebook/social integration, don't you?
Then there's this weird habit of people: they've got calendars and tasks on them. Wouldn't it be great if the crumbs are linked to calendar and/or outlook-task items?
Sooo... This is my (already quite complex) idea. To conclude things once again: the outlook task system isn't capable of managing real tasks. You can give certain progress percentages, but that's just something that could be managed by this app, since it's much more in depth.
Problem is, I'm not that good at developing (yet)! So if any developer out there is willing to take this thing on with me (I just feel this could turn out great), please let me know. Meanwhile, I'll keep dreaming on and I'm a quick learner, so I hope to show a mockup of some sorts soon . I've already thought out some sort of menu structure/frame everything should be hung up in and that's what I'll be working on the time to come.
And keep in mind:
This idea is NOT for sharing by anyone but me right now. That it may be very clear that this idea is not for your own use!