search

timheuer / callisto

A control toolkit for Windows 8 XAML applications. Contains some UI controls to make it easier to create Windows UI style apps for the Windows Store in accordance with Windows UI guidelines.
http://timheuer.com/blog/archive/2012/05/31/introducing-callisto-a-xaml-toolkit-for-metro-apps.aspx
Other
338 stars 108 forks source link

CurrentAppManager #127

Open scottdorman opened 11 years ago

scottdorman commented 11 years ago

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 commented 11 years ago

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

scottdorman commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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

scottdorman commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

Any updates on what was decided about this?