Comparison of GetJar vs. Tapjoy "virtual currency" model

There might be some confusion for some developers about the various “virtual currency” models.

Tapjoy is simpler than GetJar because:
- Tapjoy servers only store a "Tapjoy balance"
	which is currency they have accumulated VIA YOUR APP by completing offers

	so it essentially reflects the revenue you have collected from them ALREADY

	you can then use this balance internally in your app to allow them to unlock features etc.

	so practically you may store local Shared Preferences:

	- a local copy of last retreived Tapjoy balance
	- product X was bought
	- product Y was bought
	- how much was spent from that balance so far in buying the above products (NOTE: you can even make this NEGATIVE if say you want to give an initial balance to user so the first product is easier to buy etc.)

	on screen you can show the Tapjoy balance MINUS the local Shared Preference for how much was spent

	this creates a very clean interface to Tapjoy servers - as only one number to retrieve
	(when you query - you specify a callback - which could update a total balance view in your activity also)
	usually results are received within 10 seconds from Tapjoy servers even on slow GPRS connections

	in case you lose local data i.e. user did a "Clear Data"
	you can retreive the Tapjoy balance
	and just show no products bought yet
	and also nothing spent yet

	the user can then build up their purchases again from their Tapjoy balance

	this sense of Tapjoy managed balance is called a "managed currency"
	you can also setup "unmanaged currency" (which would generally be used for a "consumable" type currency where you are not keeping track of total earned etc.)
	(I think if you setup a managed currency for an "app" you cannot setup an unmanaged one - or some detail like that)

Now compare to GetJar ..

- GetJar remembers no such app-specific balance, but only a series of "products" that were bought

	there IS a concept of a GetJar balance but it is not app-specific
	but is a universal balance that the user holds (i.e. their "wallet" that they can spend across apps)

	this balance is not available to the developer to subtract at will
	(only can subtract by going through the GetJar purchase UI sequence etc.)

	the ADVANTAGE of this is that the user may have some loyalty as they maintain
	a universal balance at GetJar (though in reality Tapjoy seems to be more familiar to users than GetJar)

	AND a user can spend extra balance earned while doing something at one app - and use that extra balance in another app to buy something

	in fact GetJar had (or were planning) a capability where user could BUY virtual currency in one app - and spend it in another
	(this would be useful for apps/developers who cannot charge Google payments yet in their location)

	HOWEVER, GetJar did not create some "bank" apps - which would allow payment to GetJar and then use that in your app - so the full potential for this was not realized ..

	In addition the incorporation of GetJar SDK is 100x harder than Tapjoy - because their sample apps exposed a LOT of complexity to the developer (who may initially just want to get things going)

	In addition the GetJar servers or interface was SLOW - not as responsive - plus because it manages "products" there is a logistical complexity to the developer to communicate with GetJar to manage all the various "products" being bought etc. - though "unmanaged purchase" - where GetJar does not remember is an option also (but then the risk is that a purchase could be lost - with a managed balance the advantage is that if the developer feels some callback was missed due to internet loss etc. the balance can LATER be refreshed and eventually everything will be synched).  However when there are multiple "products" to manage it raises the complexity - and also of managing the code at the developer end.  As every change will require adding to the GetJar-specific code also etc. ..

	Making matters worse - the GetJar SDK integration leads to UNNECESSARY dialog boxes "Please Wait" appearing when none should have been needed - for example if your app quietly wants to query the GetJar server - for something the "Please Wait" dialog box appears.

	Additionally the coding also includes a far more complex series of changes you need to do to your app to "integrate the GetJar SDK".
	Also the GetJar stuff requires a whole bunch of extra permissions - GET_TASK, GET_BILLING etc. ..

	In comparison the Tapjoy SDK just has a simple callback - and the permissions are fewer also.

this difference makes for a simpler implementation for Tapjoy
	since as a developer you only need to be bothered by ONE number
	the user's Tapjoy balance

	Tapjoy balance - which is what has already been earned by the developer
	the developer can manage how the user is going to be charged from this balance etc.
	(as outlined above - by remembering which "products" they bought and how much was spent etc.)

	thus if you create an activity that manages the "Store"
	(where products can be bought with the Tapjoy "virtual currency")
	the activity only needs to read local Shared Preferences
	and then perhaps queue a query to Tapjoy servers for the Tapjoy balance
	which will usually arrive in 10 seconds on a slow GPRS connection even

	in the activity you can update the total balance from the callback
	(once the balance is received from Tapjoy servers)

	in contrast with GetJar you have no access to a "balance"
	but only "products"
	thus there is a logistically harder juggling act to get all the products that
	registered as bought etc.
	thus there can be a "slip between the cup and the lip"
	with so many async things happening ..

Anyway, hopefully this will provide a bird's eye view of the two virtual currency ad networks.

A clarification to the above negative assessment of GetJar:

GetJar is undergoing some change it seems - they have revamped some of their pages - however I fear they maybe doing things incrementally, when they may need to RADICALLY rethink their whole system.

The problem maybe that their initial group of engineers and the DESIGN they created - may have too much of a legacy impact on what they do - and may limit their server responsiveness etc.

It would have been simpler if GetJar understood the STRUCTURAL superiority of the SIMPLER Tapjoy system - and did something similar.

However GetJar, being a company that preceded the Android revolution, may have some serious legacy baggage to shed - which may not just lie in it's SDK, it's engineers etc. - but possibly in upper management (?)