424 karma · joined April 15, 2010
As for 'simpler', as long as you aren't actually implementing the thread safe map, it is simpler than using memcache too.
So as long as you use well written shared state implementations, (e.g. Java's concurrent collections), shared state isn't as hard as you make it out to be.
That is absolutely not the point raised in the article. XML based declarative UIs help to keep your view code separate from the application's logic allowing for faster iterations. I don't think anyone manipulates XML views in code except in corner cases.
The simplest way to get a big picture idea about Android's XML based UI is to think of them as HTML+CSS with the addition of good layout managers.
Moreover, searching for anything old on Twitter is pretty much impossible. Delicious was much better in that you could always search & recall that one bookmark.
So they hired a consulting firm and paid them about half a million dollars (IIRC) to come up with a new name.
In the end, the name they picked was.. Marina Bay. Yes, half a million to just continue with the old name! The spin was that the name was good and already part of the national culture/image. Which, to the layman, was obvious from the start :-)
[1]: http://developer.android.com/guide/topics/data/backup.html#S...
You mean like Apple?
You mean Ice Cream Sandwich? Google has made it clear that they won't be making a Honeycomb source drop. Instead, ICS would contain the 'converged' codebase from their phone (Gingerbread) and tablet (Honeycomb) trees.
This generally affects sales involving large quantities. Say you want to sell 10000 of IBM. The current order book at the exchange looks like:
165.55 - 10
165.54 - 20
165.53 - 200
165.52 - 500
165.51 - 100
Market Order: As soon as you place your order, you are going to sweep the order book above. End of those 5 transactions, the market has moved to 165.51 while you've only liquidated 830 of your 10000! Worse, people are noticing a lot of sell activity so the folks who wanted to buy start placing bids at lower & lower prices. By the time you liquidate all your 10000 stocks, the average price you end up getting would be 165 or 164 or lower! You've moved the market by virtue of your sale & made less money as a result.
Limit Order: If you place a limit order for SELL 10000@165.55, then you sell the first 10 to the current highest bid. After that, everyone knows there's a seller looking to offload 10000 units. So they lower their bids. You are worse off!
By now, I hope it is clear why you should care about not moving the market by your sale. The way to solve this problem is to sell in small chunks periodically in ways that does not signal to the market what your actual quantity is. As you can imagine, computers are pretty good at doing this kind of grunt work. Hence Algorithmic trading :-) Specific examples would be VWAP, TWAP, etc. Just Google for them.
PS: this has nothing to do with HFT algos.
You've got to separate Java the language from all the other stuff. You aren't going to use J2EE for Android so how does that affect you? Java may not be the most elegant language but neither is Objective-C without warts.
> And, more importantly, the market isn't just there for Android apps.
Now you are just moving the discussion.. this is not what the OP was talking about nor was it the point of this discussion.
Goes both ways, no? Not that your comment is without merit but this bit just struck me as really odd.
Consumer buys that device, loads up the Market & tries looking for my app which their friend said was MUST HAVE. They don't find it on the Market so go back to the store, return the device & get another.
I think this is what kogir is talking about. Feel free to replace GPS with such things as broken OpenGL implementation, etc.
G+ profiles have nicknames. Wouldn't that be suitable for this scenario?
As an Android developer and a long time Android phone user, I have to say that this can _never_ happen. Do you have a real example?
1USD ~ 1.3SGD