haseman

If you like wearing more than one popped collar, move to north beach. Otherwise, live in the Mission, Lower Haight, or Soma.

It was only a matter of time. The same thing happened on Verizon's 'Get It Now' store.

Apple and Google have brought a lot of new people into our industry. There's going to be a learning curve, and it's going to be painful for all of us at first.

We work around this problem with our own XML runtime parsed UI Library. It lets us have a set of layout files for each screen size of the application. Since we've implemented it for almost every platform out there, it means I'm mostly writing application logic. (Which has it's own set of pitfalls)

As much as I hate buzzwords, it really helps to take an MVC approach to mobile development. Different screensizes and input methods just require different views on top of the application logic.

It's Fake Steve Jobs. I imagine it's a little tongue-in-cheek...

The unhelpful answer is: it depends.

Obviously, you should design your application to reach as many people as you can with a core set of functionality. For us, this means passing on possibilities that work only on a small set of devices. (Unless that small pool can generate enormous revenue)

Further, we add nice-to-have features to our core app that can be switched on and off at build or run-time by our QA team depending on the device.

Sorry I can't be more specific. If you're looking for more information feel free to email me. :-)

Mobile software is hard.

At our company (small mobile software shop) we currently have ant scripts that churn out builds for over 100 devices with at least 10 different screen sizes and many different input methods touch/dpad/trackball. On one binary. These things can be done, it just takes work.

Anyone telling you that the App Store is still a gold rush is trying to sell you something.

"That's right: The biggest and most notoriously closed wireless carrier on Earth is partnering with the biggest and most open Internet company ever, to bring Google's new Android phone platform to users who want a truly expandable smart phone, yet still require a robust and dependable carrier."

Anyone who thinks that Verizon's Android phones will be 'open' has never written mobile software that'll run on their network. I'm really hoping to be wrong about this, but historically Verizon's track-record is to lock down any platform on their network.

Turns out, being sarcastic is hard. Wasn't trying to start a flame war, just making a simple snarky comment.

That may be so, but apple will never let you ship an app they haven't approved. They have very specific language forbidding VM's and interpreted languages. So you may be able to dodge Objective C (like the Mono/Unity folks have) but you're not getting out of Apple's approval process.

How to outsmart Google? Easy in just a few steps:

First, overthrow whatever governmental system is currently in power.

Second, install a 'communist' government who is friendly to your business.

...

Profit!

The demise of the American Empire has been predicted for decades. While this guy makes some good points about how the economy isn't fixed, they get lost in his sensationalist rhetoric.

All I can say, after several years of Mobile development, is: Thank God.

We've been relegated to the dusty corners of the consumer market for so long. It's amazing to see the mainstream web services community catching on. Now we mobile guys just have to keep up...

I've been writing mobile software for a few years and I'd wholeheartedly agree with the first two. The third I would be less religious about... you should always listen to your customers, but you should be driving the buss, not them. Good article, mobile in general is very much not the web, or anything else really. Further, writing software for the iPhone and Android is several orders of magnitude easier than writing Brew or Java ME software for the ability to easily publish updates alone.

Excellent set of links! Thanks!

What if the turtle's universe was a dream thought up by the great flying spaghetti monster?

My probability math is rusty, but it's my understanding that probability is only relevant in a finite system. The article (in a very sneaky way) assumes, as it's premise, an infinite set of 'simulations'. But if this is the case, wouldn't that negate the usefulness of their 'probability'? In other words, if your conclusion is that we could be living in a simulation running inside a simulation running insi.....(keep going until blue in the face) doesn't that undercut your ability to say that one course of action is more likely than another?

Or, even better, isn't this the same as the proof for god that goes: "Our world is so complex and the probability of it coming about by by accident is so small that there must be an intelligent being controlling it'

(I was a CS/Philosophy double major in college, so my theoretical probability skills may be off, are there any math majors out there that can clear this up?)

A modern rehash of René Descartes's "I think therefore I am" problem. He asked, essentially, am I living a fantasy dreamed up for me by a "great deceiver". Replace "great deceiver" with "computer simulation" and the argument plays out the same way (albeit, with more probability in the modern case)

Ultimately, your existence is exactly what you perceive it to be. Speculating on the nature of our existence, on this level, is indicative of those who don't have to pay their own rent :-) You can chase your own tail on this one literally forever. As we cannot access the simulation we are running in (just as you can't really think about thinking) this idea becomes a debate on par with the existence of God. It cannot be proven one way or another.

All this aside, I'll admit it was a fun read.

I've had success in asking for a raise with a technique that breaks down into two parts:

First, frame the issue as a problem for you. A problem your bosses can help you with: I.E. your unhappy about the mismatch between your salary and your responsibilities. You leave step one when your bosses agree with you that it's a problem. I'd try to stay away from specific numbers and focus on your needs/feelings. Be general, talk about how others in your area are paid more, but shy away from exactly how much. This allows your manager to 'help' you with your problem without a commitment to what the 'help' might look like. Bosses _love_ to be helpful.

Second, once they admit that there is a problem, you can start talking about a solution. Remember, your bosse's hands may be tied with rules about max raises, bonus schedules, review cycles, and other such crap the corporate world throws in front of good bosses. So, before hand, figure out what solutions you'd be willing to accept. Maybe a deferred raise, bonus, more vacation, less work hours for the same pay. Try to be as flexible and honest as you can. The second stage is your time to start talking about specifics, but try to accommodate the limitations placed on your boss. That said, do your homework, if your boss is lying to you, don't call them out, just get ready to walk.

Last, be prepared to quit. It's hard to talk about how unhappy you are at your job if you haven't thought about alternatives. If it goes well you won't have to leave, but it's good to go into the discussion with the confidence that you could quit if you had to.

Good luck!

One of the great things about the internet is it's always about to change.

I think these services have interesting models....but I'll be damned if I'm going to let a 'sales tax calculator' blow a sale because it goes down. A rational business cannot rely on services they can't, at least in some small way, control.

Technology isn't hurting our brains. It's evolving them to deal with a different set of problems.

I think the other comments on this thread may have missed something. The problem isn't that your personal information is revealed upon purchase. The problem is that Android applications, with their "phone home" tech, allow some really creepy locational tracking. If you buy my GPS app, I now have your name, phone number....AND I can find out exactly where you are every time you use my application.

It's not the personal information that raises hair on the back of my neck, it's that in combination with the ability to track your exact location in conjunction with the aforementioned information.

While sending your info to merchants you purchase from may be a 'no duh' piece of information...it does raise some tricky implications.

Gravity Mobile of San Francisco, CA is hiring talented mobile engineers. We prefer Java/C/C++ programmers with experience in Java ME, WinMo, Pre, or BREW but would consider iPhone developers with a track-record of published applications. Here's our website (http://www.gravitymobile.com)

We're a small boutique software house. (Less than 20 people) However, we work directly with some of the biggest companies out there. (Verizon, AT&T, Major League Baseball, Pandora)

While not a startup (we're a subsidiary of Gracenote which is a subsidiary of Sony corp) we like to work in 'startup' mode as much as possible (except the crazy hours)

If you're interested, and can legally work in the States, email haseman -at- gravitymobile +dot+ com

Yes, if you don't mind pushing it.

I'd be interested to hear your thoughts on what would make it better.

Find me an article that isn't '1000 subjective words' :-)

I actually wrote the linked article in response to all the 'this is what makes a good programmer' articles I've seen going by on Hacker News. It isn't the end-all, it's just more perspective. I'd also add that it doesn't describe me as well as I would like.

What Layar makes is neat, but finding rental places, I would argue, is actually better done through a mapping interface. I've seen their videos and it still looks like a toy interface. Nice to play with...but lacking an serious work potential

Sure, the potential is great. But none of the things you've mentioned really 'require' the AR component. They could all be done just as well with a good Google Maps interface. This is what I say when I mean it's a 'gimmic'. These are all great ideas, but they could be done just as well (except the last example), and for less money, using existing tech

Have you done any development with J2ME devices? In the past few years I've done it..it's been a nightmare

I think it's a gimmic right now...as the sensors (3gs and Android devices) aren't fast enough to make it really use-able. The thing I wonder about is...is there enough movement to convince OEM's to put better sensors in their phones?