[XAP] Phone Commander

Hey man, sounds ambitiously, with the declared functionality it would be a perfect tool Good luck!

I think I will check this out

Hi Martin,
first look i like your commander.
I will wait next version, good work

Looks *very* cool! Makes me wish my HD7 had a hardware keyboard though; this will be hard enough to use with touch on a 4.3" screen and will be a lot harder on something like the Surround or Trophy. I must admit that the inspiration (two-panel file managers, which date back to at least Midnight Commander and possibly further) appeals strongly to my nerd side.

I'll try my best to make sure that HtcRoot is available for this to use on as many phones as possible (probably all first-gen HTC, second-gen may never be possible without a new exploit).

One suggestion: just make the file lists scrollable using swipes (it's a built-in control that you put the other controls within). The scrollbars take up non-trivial screen space and are actually kind of hard to use with fingers. Also, tapping on "ext" is *way* harder than it looks like it should be; even moving in tiny increments I tend to go from tapping "FileName" to tapping "datetime" directly.

i am looking for a function that auto on/off 3G had scheduled times, much like what android apps do

is this possible with yr xap??

Martin7Pro said:

Scheduling is in the future plane. I have a lot of to do with higher priority first. I seen any "Tasks" application on MarketPlace for scheduling. Try it, may be it is able to schedule system changing.

Click to expand...

Click to collapse

those apps in the marketplace only give u a reminder.

i need the app actually disable/enable things at a given time.

If I understand what you're asking about correctly, multiple interface inheritance is probably your best bet, since .NET doesn't support multiple class inheritance. This usually means you need to have some kind of external factory as well, since interfaces can't have constructors or static methods.

Implementation-wise, one way to do this is to simply wrap the older objects, and pass calls to their interfaces through to them. This isn't ideal and still requires non-trivial coding, but it does provide good encasulation and relatively good code sharing. Dependency injection using Reflection APIs is certainly also possible, but requires some work.

Thanks man looks very good

I think that doing this is going to require the use of the Reflection APIs. In essense, these let you load assemblies (collections of classes, typically in namespaces) from .DLL files (by name), and let you load classes from within assemblies, and let you call functions of those classes.

Probably the easiest way to do it is a function pointer table. In .NET, function pointers are called "Delegates" and are technically objects (like everything, including primitive types) but they pretty much work exactly like strongly typed C++ function pointers.

When the app starts up, it looks in a known location (or possibly queries the registry, or something) for DLLs containing extensions. It then loads the assemblies from those DLLs. Each assembly should have a registration function (probably a static method o a static class) that returns a collection of delegates (and their priorities, if needed). Your app then uses those to build a function table that it uses whenever it needs to do a specific type of operation.

For example, you could have one entry in the table for "WriteFile" and might get function pointers for it from one assembly that uses the native APIs with no special permissions (works for some custom ROMs, or after using HtcRoot), one that uses isolated storage APIs (works for any ROM, but only to a specific folder), one that uses HtcFileUtility.dll (the driver that TouchXplorer uses), one that uses ntive APIs but wraps every call in an elevation call to HtcRoot, etc. It would be up to the framework (meaning up to you, if you're designing it) to define some way to indicate which one to use.


All that said, while extensibility is an excellent goal and probably necessary in the long run, you might want to just get a proof-of-concept working that is hard-coded to use a single known approach. Reflection isn't actually that difficult, but it seems like a distraction from getting a first version out the door. Release early, release often, and all that.

very cool

good luck

Martin7Pro said:

I am working on TCMD equivalent for Windows Phone. It may be:
Two-panel filemanager,
SMS and Mail configurator (groups, searching, backup),
Registry editor (editing, export, import),
Taskmanager (working apps dehydrating, resuming, closing, memory increasing),
Tiles configurator (creating, grouping),
MultiMedia manager (searching, playing etc.),
Applications configurator (uninstalling, grouping),
Keyboard Shortcuts configurator (HTC 7 Pro, Gold, Prime),
and another next by plugins system.

It will use direct access for unlocked ROMs, HtcRoot project (http://xdaforums.com/showthread.php?t=1453343) for full access on (dev and) InterOP unlocked devices (where it is possible), ProvXML method for incompatible devices.

There is first screenshot:

There is also Pre-Alpha User Interface demo only xap.

Try it, post experiences. This is designed for HTC7Pro hardware keyboard, but must be usable for touch conntrolling too. For big dirrectories (\Windows etc.) scrollbars are necessary. I want to have as far as possible biggest amount of controls on main screen. It may not be a game, it must be working tool. In long future I want integrate also simple programming IDE to this tool.

Click to expand...

Click to collapse

Err, why are you using drive letters like C:\? We all know Windows CE doesn't use such things. I think adding artificial drive letter paths will just confuse users in the long run. If they're going to be navigating the filesystem, they might as well learn how to do it right. But if you really must do this, at least make it easily disabled.

Also, are those native Windows CE common controls in the screenshot?

@Martin7Pro: One suggestion: with the semi-imminent release of WP7 Root Tools 0.9, which will allow elevating arbitrary apps (and will support more devices than the HtcRoot project), I suggest you focus on just using native APIs and don't worry about permissions. It will already work on full-unlocked ROMs, it will work on all devices that are supported by WP7 Root Tools once it releases, and it will be easy to add support for HtcRoot if for some reason that saspect of the project is still relevant.

I've got some exciting other directions I want to go with HtcRoot, like seeing whether I can modify ROM files or do other crazy things like that (it might be possible, what with the ability to tweak driver code directly). The elevation to TCB ("Admin") and policy-engine work was (and still is) a stepping stone to get there, but with WP7 Root Tools 0.9 supporting the most important policy engine changes directly, that's less of a concern now.