jo_

I've found the only sure-fire way I have is to write my own GUI display[1]. I understand it's a bad idea to do stuff like that, but I heavily on inputs which are outside the standard repertoire. Unless there is a standard widget in a GUI toolkit which lets me enter 2D points overlaid on a procedurally generated image with scrolling support.

[1]Except Swing, which allows me to override paintComponent.

You're probably right. I'm not convinced you're right, but I'll operate on the assumption you are and offer a feeble defense with anecdotal (and experiential) evidence to explain why I would rather use Android UI but consistently turn to PhoneGap.

I knew Java first, then picked up HTML/CSS/JS on my own. I'm cozy enough with Swing and I'm getting there with JavaFX.

I would rather develop in Java with Swing or even JavaFX. I reach for PhoneGap because I can develop my application 'live'. Make code changes, switch windows, changes are live. I can pull up the UI panel and make adjustments to styles to see what looks good. I can test the entire application and debug it before I push it to my device. If something fails to load, I can see why without waiting for an emulator to spin up and without pushing to the device. Plus, if the application crashes in my browser, I can pull up the debug console and step through it. I'm sure all these things are possible with ADB, too. There are lots of little things which irritate me with native Android development. I'm still releasing apps and every so often I try to do a native one. Whenever I do, though, I always find myself stuck on something that seems infuriatingly simple or clear -- something that 'Just Shouldn't Happen," and I look over at PhoneGap and I know that, despite JS being kinda' shitty, and despite the lack of consistency in HTML5/CSS, it still beckons for silly reasons like, "Small annoyances are more soluble! You don't have to rebuild and reupload to fix a null-pointer error! You can use the REPL to play with objects in memory!" and so on.

Maybe I am reluctant to learn the nuance of Android UI on a subconscious level. Maybe I'm reinforcing my own beliefs when I sit down with an Android UI book or go through the UI tutorials online. I've just never felt the workflow was very intuitive, and the small (though frequent) irritations are enough to drive me back to something which is worse architecturally and more time consuming in the long run, but doesn't have the little things that make it unpleasant to work.

CAR ANALOGY! I have two routes to work: one of them is short, but goes directly through the city and has a crazy merge that I need to do to get there. Some days I take this route because "it would be totally great if I'd just get familiar with it," and I start out fine. Except for the insane merge which is backed up for a few blocks. I'm driving fine, and I feel like now that it's over I'm home free. Oh. This street has construction. Sudden stops. My head is starting to hurt. Nearly half way there. Okay, I don't see a way around this route. I have to backtrack because I made a wrong turn early on. More construction. Traffic lights that aren't working right (or are, but I'm mixing them up with the ones facing perpendicular traffic). Finally at work. I'm irritable and still have a whole day ahead of me.

The other route is really long. I get on the onramp and it's slow but I'm always moving. Quick scuttle and I'm free to drive. The roads are unfinished and there's an omnipresent farty smell, but I'm moving at a comfortable pace and I'm pretty relaxed. Oh, the bridge my route takes is out. Well, I'll travel down the way a bit. No problem, though it's going to take longer. Swoop around and I arrive at my destination. On the way there I also picked up a Strawman at a barn to use in my analogy.

I feel like this overlooks one of the more fundamental problems to Android development. It's not an issue with Java, it's an issue of Android being a cathedral of complexity. There are four dozen ways to accomplish the same tasks, each of which utilizes a different (but ultimately incompatible) piece of the API. You can build your Activity and embed your Fragment in it which houses a ListView to display your--- wait no maybe I should override ListView. No, people say that's a bad idea. Okay I'll override this object which ListView displays. Okay that kinda' works well enough. I'll figure out how to style that later. Okay now I need this thing to go to this other activity when cli-- maybe I should just replace the Fragment, since we're kinda' using the same data. No wait. I'll change the activity. Okay it looks like there's no function to do that. I'll go back to changing the Fragment to something else. Okay, that's giving me an exception. Lemme find where I can change the Activity... Oh, I have to do it elsewhere. Well I can hack my way around that.

It doesn't end.

"Button is actually a special type of view with extra properties." Great, so everything is a... You know what, I don't care. I feel like I did in the mid 2000's with game development: there are a thousand libraries which each are so complex that it's impossible to get good work out of them. Instead, I always ended up falling back to the simplest home-rolled solution. Except in the case of Android, there's really nothing more fundamental. I can (and do) use PhoneGap because it makes my life _significantly_ easier in many respects, but I think Android really needs to be restructured on a more fundamental level.

I remember seeing this during the 'tape to car wheel' test. That was impressive.

What, if any, details can you reveal about the implementation? How is the tracking/smoothing different than other SOTA approaches?

How tightly coupled are you to the Apple environment? Is an Android port plausible?

I'll concur with this on most levels. The change I made was from a slightly different place: boxing. I joined a school that did BJJ and Muay Thai.

It worked out beautifully. After staring at a screen and sitting down for 8-10 hours, I could spend an hour or two getting the shit kicked out of me. Since I lived in the city and was traveling against traffic, it had a chance to die down while I was working out. Aside from the endorphin rush that accompanied the workout and the physical changes that accompanied struggling to the point of immobility 3x/wk, I got a nice confidence boost which stayed with me through most of the job interviews that followed after I relocated. It was like all the panic and nervousness of the week got expelled in the span of six hours. For six months after I stopped (moved across the country for grad school) I could sit through job interviews thinking, "There is nothing this person can do to me physically, mentally, or socially which I cannot handle. This person has no power over me. I am in control. I am the authority."

I might try ballroom dancing when I have the time again, as I think it's more practical from a social perspective than fightin'. (Seriously. The knowledge and confidence to dance wins 10/10 in social scenarios.) Still, try both!

In a similar vein, I had an idea for a social site where everyone was invited via other people, establishing the chain of invites. Spamming from one of the leaf nodes propagates upwards as bad karma, decreasing exponentially (or by some power, depending on how strict you want to be about anti-spam ruling) with each parent step. If the inviter's karma drops below a certain threshold, he/she can't invite more people. If it drops lower still, the branch dies and everyone on it gets banned.

This is probably not a great user experience (getting banned because someone above you invited a bunch of spammers), but I think it's conceptually interesting to distribute the anti-spam onus to the users of the community instead of the administration in a form other than 'report spam'.

Woww. Such clever. Much compile.

I've been trying to get Hamiyoca's JS miner to work with mupool without much success. (Stratum is straitforward. I'm just dumb.) p2pool is way easier from the cursory glance I've given it. I'm surprised I hadn't heard of it before.

Any chance I could trouble you for an invite for jo.jcat at gmail? I'm already using proof-of-work to keep spam off my blog (josephcatrambone.com), but I wouldn't mind switching early to something more conducive. Hell, if the payouts are nonzero when they roll around, I might be able to strip the ads. Alternatively, what's the official way to request an invite? Sign up for the news letter and wait?

If you start calculating the hash in the background, that could be useful. I might not want to wait 100 seconds after I've finished my reply, but I don't imagine I'd mind waiting 100 seconds from the time I first opened the thread or started typing.

Thank you for making it. (I'll beg you for an invite later.)

I'd experimented with embedding Javascript Bitcoin miners in my website as a means of monetization without ads. I see this as a more intuitive version of that which restricts the user based on usage (posting rate) instead of on viewership.

The issue I encountered was a miniscule rate of return on the JS-based mining. Do you think that if HashCash integrates with BitCoin for monetization/mining purposes, JS speed will be a limiting factor?

The point of a simulator is it drives deployment time to zero and increases the number of virtual devices on which you can run without adding a new AVD for each. Deploying to a phone takes maybe 40-60 seconds? Maybe less? But I'm not a very patient person. At 60 seconds per deploy, if I make a tiny tweak and then have to wait a full minute for feedback on how it feels, it has become a slow and arduous process to develop. If I deploy to device and immediately discover a null-pointer exception, then that's 120 seconds of my day gone. The amount of time is even longer for an emulator, where it can be as long as five or ten minutes.

Your first point is particularly interesting to me. It was my understanding that Javascript was impossibly slow at a few very key operations, like array lookups. (Since it didn't have true numerically backed arrays and instead did hashtable lookups for those types of arrays.) C should be blowing away Javascript in pure array lookups. I'm astonished it's not. What do you suspect is the cause of that?

Sent. :)

That was my fault. I was fiddling around and played with sending some raw data over the socket, then it crashed.

I'm so sorry. I crashed your room. Can I send you an e-mail saying how I did it?

EDIT: I hesitate to post my e-mail to HN or to paste publicly how I did it, but it was trivial. Reply with your e-mail and I'll show you how I did it. It's probably a simple fix.

Writing software is 60% understanding the problem, 25% understanding the tools, 20% understainding requirements, and -5% hacking the solution to make it fit requirements.

Strangely, every one of the links in the downloads page has 404'd for me. I was quite disappointed to see Wave die, since I think it was both incredibly forward looking on Google's part and, all things considered, immensely useful. I wish it could have become the email replacement it wanted to be. It suffered greatly, though, from higher latency, intermittent bugs, and lack of (very) widespread adoption.

Part of the reason I asked if I could cancel my preorder of Dev Kit 2 was some bad experience with Facebook dicking devs early on. Unless they've changed their tune in recent years, I don't understand how this could bode well for their support audience.

I remember being surprised that the bottleneck for some modern devices (like cell phones) wasn't the number of vertices one could push, but rather the fill rate and number of draw calls. Do consoles these days hit performance bounds as a function of the number of draw calls rather than the number of polygons/vertices?

I ask because I can completely understand how doubling the number of draw calls could be problematic in a VR situation.

Speaking purely from the backend, our login function takes the IP address of the requester, the login name, and password, then checks the password against the database. If the password matches up, the current date and time, the current IP, the current time, the session expiration date, and a buttload of details about the host machine are hashed together and encrypted with the system's public key before being sent back as a token.

It's up to the client to store the token however it likes, but our reference implementation stores it as a cookie on the local machine.

If a new request comes from an IP address which doesn't match the encrypted token, or if there are system details in the encrypted token which don't match up with the one on file (we restrict sessions to single instances), then the request is rejected.