CurrentAppManager

[scottdorman]

Added a CurrentAppManager singleton to simplify app license management.
This allows you to always code to the same API to rather than having to
change code between CurrentApp and CurrentAppSimulator, which makes it
easier to submit apps to the store without leaving calls to
CurrentAppSimulator in place.

[timheuer]

Nice. Regarding namespace...given it isn't directly Control related...Extensions (or perhaps a new classification for this utility aspect)?

[scottdorman]

I didn't really know where it belonged. I put it here since that's where the AppSettings class pretty much ended up (which also isn't directly control related). I'm good with whatever makes the most sense. Extensions is a possibility, but it isn't really an extension to anything, more of a wrapper...maybe ComponentModel?

Glad you like it, by the way. Solves a major pain point for me and probably a lot of others too. Didn't find anything else like it so I wrote my own. :)

[dotMorten]

ComponentModel is usually used for something else. How about "Utilities" ? Or "Store" ?

Btw. I usually use this approach instead with an alias:
http://www.sharpgis.net/post/2012/11/26/A-simple-way-to-use-App-Simulator-for-App-Purchases.aspx

[scottdorman]

Cool approach. Had that post been out last month when I wrote my class, I probably wouldn't have written it. I'm good with whatever namespace you both feel makes the most sense. Either of those are good choices.

[dotMorten]

Well I have to admit I wrote the blogpost after seeing this and figured I would share :)

[scottdorman]

Always more than one way to solve a problem. :) would have been nice if we didn't have to solve this problem in the first place but the fact that we do means Microsoft solved some other more complicated problems for us. :)

[timheuer]

Scott do you feel this is necessary/value-add above the alias approach (I always forget about those!)? Would hate to add code just for the sake of it if there is a method that does less execution logic.

[scottdorman]

I'm probably a bit biased, but I do feel this adds value above the alias approach for several reasons:

1. I always forget that I can do that as well, and I'm sure we aren't the only ones.
2. The alias approach requires you to add the same #if logic on every page, which can be error prone if you forget to add it somewhere.

This approach allows you to use almost the same calls as you would with CurrentApp or CurrentAppSimulator (methods/properties are the same), doesn't require additional logic on each page and allows you to easily override the switch to use the simulator for explicit testing.

The alias approach does have the advantage of not performing the execution logic with each call, although that is a single conditional branch. I think the ease of use outweighs any potential performance penalty caused by the conditional evaluation. I have this code in all 5 of the apps I just submitted and didn't notice any differences in my testing after I started using it.

[scottdorman]

Any updates on what was decided about this?