Reputation: 42 Craftsman
- Active Posts:
- 670 (0.36 per day)
- 30-June 09
- Profile Views:
- Last Active:
- Jun 23 2014 01:23 PM
- OS Preference:
- Favorite Browser:
- Favorite Processor:
- Favorite Gaming Platform:
- Your Car:
- Who Cares
- Dream Kudos:
Posts I've Made
Posted 7 Jun 2014As a note to readers, there is an error in the source code archive.
In Engine.java, the second line of the constructor reads if (singleton != null)
It SHOULD read if (singleton == null)
My apologies for the oversight.
Posted 20 May 2014Hi Tenacious
I'd like to see if we can work this out. Could you provide a full code listing for your application so I can recreate the problem my end?
Posted 20 May 2014My, rather default, response to this is a database. You could store the hashed and salted (!) email addresses, usernames and ip addresses plus a true/false value denoting whether some has or hasn't supported the game. When that user logs in, pull the true/false value and store it in a local variable. That way you could use a simple if statement where supporter-only features would come into play.
It's less than elegant, but it's simple enough.
Also, using the database would give you the back end you're after. Largely, though, you'll want a pre built solution for something like this as opposed to writing your own. The approach you take is directly proportional to your data needs. Either way, you'll be using a database - the question is how you'll interface with it.
Posted 29 Apr 2014@farrell2k:
Locking on an object of the Singleton class ensures there's no volatility whatsoever (more or less) if nothing else can access it, whereas locking on Singleton.class doesn't necessarily have the same level of security in terms of concurrent access. I also thought that might help with the out of order execution, but I was wrong. That was all, apologies for the confusion.
Posted 29 Apr 2014I wouldn't advice synchronizing on Singleton.class
Other classes could, in theory, be synchronizing on the same object
Instead I would have a private static object to use as lock
Seems unnecessary to me. Elaborate a little more if you would, my good fellow. />/>/>/> What's the difference?
The difference is that Singleton.class can be accessed from any class, any method, everywhere
Using a private class instance, not shared with any others, will ensure no outsiders are synchronizing on the same object
I imagine this would be a quicker and less-dirty solution than thread blocking, too. I'll plug it in in a bit and see what happens. May end up updating the tutorial next time round.
[Edit] Maybe not, but it was educational to have a look-see none the less. It still serves as a more secure anti-volatility mechanism.
- Member Title:
- The Leafiest of the Leif's
- 21 years old
- February 5, 1993
- Wolverhampton, UK
- Interesting things. Interestingly.
- Full Name:
- Leif Walker-Grant
- Years Programming:
- Programming Languages:
Experienced: C#, VB, (X)HTML, JScript, PHP, XAML, ASP, VBScript, C++/C, Java.
Some Knowledge: Actionscript, Lua.
Designed himself: SkySkrypt Object Markup Extensions (for Project 'Skylark')