Zhephree

Dear HP,

I love developing for webOS. It’s quick, it’s intuitive, and it’s great for web devs to get into. The big reason this is is because of the Enyo JavaScript framework used to develop webOS apps. It’s a fantastic framework and is easy to learn.

I’ve written a great, unique app for the TouchPad, written in Enyo. I want to continue developing it, and I will launch it in the App Catalog. However, I would love to release the app as a web app and using my existing code would make my life a lot easier.

If I could develop web apps in Enyo and still release them in the App Catalog, I would absolutely do so. I feel a lot of people would like that option. If you’re going to make a web app and if a side effect of using Enyo to build is that it runs as a native app on any future webOS devices, why wouldn’t you?

I ask you, HP, to please release Enyo as an open source JavaScript framework. This will keep developers using a framework compatible with your OS and whenever you find a hardware partner for webOS devices, you’ll already have apps for these devices.

Think about that — in the current state of webOS, developers will not start developing for webOS right now, even though the OS hasn’t been killed. The message around the Internet is that webOS is dead, no matter what the truth may be. No one will begin being a webOS developer, which makes webOS even less attractive to hardware partners and users in the future. Open source the framework and give current developers an incentive to keep developing webOS-compatible apps. Let us release these apps as web apps or Android/iOS apps a la PhoneGap. Then, when webOS lands on some sort of hardware, we’ll be ready. New developers will feel better about jumping into it because the risk is low — if webOS fails, their apps will still run on other platforms. It’s a win-win.

Open source Enyo, please. HP, I know deep down you guys like webOS. If you didn’t, you wouldn’t have taken the chance at all. Keep webOS and its legacy alive. Keep the webOS GBU from feeling like years of their lives were wasted. Keep us developers from being hurt, and hurt financially. Open source Enyo.

Sincerely,

Geoff Gauchet,
Developer of foursquare for webOS, growlr, neato!, and incredible! 

Listen to me talk about webOS, development, the TouchPad, and some other stuff for 91 minutes!

I started this rant on Twitter, but I want to expand on some ideas here. I started this off with:

Companies only producing mobile apps for a single platform to promote a product is the modern version of “Best Viewed in Internet Explorer”

To clarify, I’m talking about apps that are basically advertisements masquerading as apps, like Absolut, Abercrombie & Fitch, Ford, and Tic-Tac. These apps exist to essentially buy ad space in the iTunes App Store. They generally just sport in-app viewing of TV commercials, store locators, etc. Nothing a mobile website couldn’t do already.

It’s a smart idea: give users something cool and fun, while advertising your brand like crazy.

There are two schools of thought for advertising: get as many eyes as possible on your advertisement, or, target a specific demographic.

In some cases, like Abercrombie & Fitch, their brand is probably targeting the iPhone crowd: people with more disposable income than most and like to stay up on what’s popular and trendy. It makes sense for them to have an iPhone app.

But what of brands like Tic-Tac and Ford? Tic-Tacs are affordable for anyone and people of all demographics eat Tic-Tacs. Why target the iPhone demographic? Same with Ford — most Ford truck drivers aren’t the iPhone crowd. 

Let’s look at some numbers. 91% of Americans use a cellphone of some kind (feature phone, flip phone, pay-as-you-go, smartphone, etc.). So, if you’re trying to hit a big market, targeting cellphone users makes sense. In theory, you’re hitting 91% of citizens.

Now, let’s say you decide to make a smartphone app. You then cut out feature/flip phone users and most pay-as-you-go users. You are now servicing 27% of cellphone users. Looking at the previous number, that means you’re targeting 24.57% of all Americans. Not terrible.

So now that you’re deciding to target smartphone users with an app, you have to choose a platform. You decide on iOS. 25% of smartphone users have an Apple device. You are now targeting 6.75% of smartphone users, which translates to 6.1425% of all Americans.

By targeting iOS only, you have brought the potential from 280 million people to see your advertisement down to 19 million. Now, this is still a great number of people, but then look that 34.4% of smartphone users download apps. You now are targeting 6.5 million people.

Does that really make sense? Out of the 6.5 million possible users, a smaller percentage will actually download your app. That number drops yet again.

Targeting only iOS makes no sense. Creating an Android version of your app adds another 15 million potential downloads — more than three times as many potential users.

Obviously, multiple platforms yields higher development costs. But, what if you could write code once and make it work on multiple platforms? Try PhoneGap. Write your apps in HTML, JavaScript, and CSS (which means you might be able to develop the app in-house, reducing costs) and then compile for iOS, Android, BlackBerry, webOS, Windows Phone, and Symbian. If your branded app is a simple app that doesn’t rely heavily of native features of the device, PhoneGap and frameworks like it can save you tons of cash and produce a larger number of potential users, yielding a much higher ROI.

It just makes sense this way. Yet, for whatever reason, everyone keeps making branded iOS apps.

In all of my apps, I use custom-colored command button widgets. They add a little personality to your apps, and don’t detract from whatever theme you’ve come up with. the webOS SDK ships with a few different colors: 2 shades of grey, red, and green, plus a dark charcoal one for dark themes. These will work for most apps, but not all.

For instance, in foursquare, I wanted to use green buttons for all major actions in the app. The standard green (class=”affirmative”) button is too green. I need more of a lime/neon green to match the foursquare colors. So, I did some research and figured it out.

So, how do you do it? Well, first off, you’ll need to make the graphics. I use Photoshop.

Find the original grey button widget PNG in the Palm SDK files. It’s in (share/refcode/webos-framework/###/images in the Palm/SDK folder). The file we want is palm-button-medium.png. Make a copy of the file in your project’s images folder and open the copy in Photoshop.

Go to Image > Adjustments > Hue/Saturation. You’ll see this dialog:

Check the Colorize box in the bottom right corner.The image of the button will probably change color to a reddish tint (if it’s anything else, that’s fine.) Let’s make a blue button. Drag the Hue slider (the first one) around until the very bottom color stripe becomes your desired color.

That’s a decent blue, but I want something deeper, and vibrant. Slide the Saturation slider over (the second one) until you get a nice, bright color.

You can see the button looks pretty nice already! Now, our app is going to have a medium-grey background, so, let’s make sure the button looks good on that background, since the button is translucent.

Click OK to save your colorization of the button. Click Layer > New > Layer. You can name the layer anything you want — we’re going to delete it later anyway. As you can see, your new layer is on top of the image.

Simply drag the new layer (Layer 1, in my example) to be under the image layer (likely, Layer 0). Now, set the foreground color to whatever color your app’s background will be and fill Layer 1 with that color. You can now see what the button will actually look like.

That looks pretty good! Now, delete your background layer (or simply hide it by clicking the eye next to the layer). Make sure you save the image as a 24-bit PNG to make sure the transparency works nicely.

Now that you have finished the graphic work, time to code it up!

In your scene’s view, you’ll want to put the HTML code for the button widget just like you normally would, but add another custom class to it so we can style it:

<div x-mojo-element="Button" class="blue-button palmbutton primary" id="checkinButton"></div>

As you can see, I added the “blue-button” class to the button. Next, let’s go ahead and style it with some CSS.

.blue-button .palm-button {  -webkit-border-image: url(../images/blue-button.png) 0 17 104 17 repeat repeat !important;  margin: 0;}
.blue-button .palm-button.selected.primary,.blue-button .palm-button.selected {  -webkit-border-image: url(../images/blue-button.png) 52 17 52 17 repeat repeat !important;}
.blue-button .palm-button.disabled.primary,.blue-button .palm-button.disabled {  -webkit-border-image: url(../images/blue-button.png) 104 17 0 17 repeat repeat !important;}

.blue-button .palm-button-wrapper {  position: relative;}
.blue-button .palm-button-wrapper .activity-spinner {  position: absolute;  right: 5px;}

By adding a new class to the button, we keep all the original buttons in tact and we’ll be able to use them in our app for less important commands.
So, that’s all there is too it! Just some points:

• Don’t overdo it: don’t make every button in your app a different color. I only change the colors of primary actions on a scene (login, check-in, etc.)
• Make sure text is still readable on your button’s background color. You can alter the CSS to change the text color if need be.
• Don’t use annoying colors. Keep it in the style of your app.

I like beer. I’ve got beer I love and beer I hate. Breweries that always delight me, and ones that always disappoint. I also love trying new beers and seeing what beer other people are drinking. And that’s where Untappd comes in. Untappd is the foursquare of beer — search for a beer, “check-in” to it to let your friends know what you’re having. After each check-in, Untappd recommends three other beers for you to try based on what you selected, what you’ve had before, and what your friends have had.

You can also rate beers, comment on them, and say where you’re drinking it (which will check you in to foursquare at the same time!). You earn badges for drinking at different places and drinking different beers, or drinking on certain days. Just like foursquare, only, with beer. 

So, if you’re a beer drinker, Untappd is essential. I’ve accepted friend requests from people I’ve never met just to see what beers they drink. I’ve been on the lookout for new brews ever since. 

Untappd launched as a web app — this allowed them to launch on all major smartphones (including webOS) quickly and cheaply, essential for a bootstrapped startup like themselves. They’ve recently launched an API to allow others to build off of their data, which is pretty awesome since I think they’re only 2 guys. I had the pleasure of meeting Greg Avola (one of the founders of Untappd) at the Palm Developer Day in NYC last year and we talked webOS and Untappd (and he was one of the first people to see incredible! in action, too). These are good guys, so, give Untappd a try!

Anyway, their API is pretty new, but already powerful. Remember that feature I said that let you say where you were drinking your beer? Well, it requires a mobile browser that supports geolocation, which, sadly, the webOS 1.4.5 web browser does not. This means the majority of webOS Untappd users can’t add their location to Untappd check-ins.

So, I took it upon myself to build one of the first native Untappd apps, and do it for webOS. This will allow fast loading (no waiting for the web) AND it’ll allow geolocation for venue adding. Plus, with foursquare opening up their venues API, things are easier than ever. 

The app? growlr. (As in “growler”, a type of beer bottle)

There’s your login screen. (minor spacing adjustments have already been made) 

So, what will growlr do? My plan for initial launch is for you to be able to search for a beer, view the beer and check-in to the beer (and attach your location). Future versions will add user profiles, your friends’ activity feeds, commenting, and more. But for now, I want to get the check-in function out because that’s the most important thing that I’m trying to improve upon (geolocation, anyway).

My aim is to launch by this weekend, so if you’re doing your St. Patrick’s Day celebrations this weekend instead of Thursday, you should be good to go!

BTW, speaking of this weekend and St. Patrick’s, check this out and maybe donate a few dollars!

In case you missed it, foursquare added a bunch of new features, including recommendations, better nearby specials, and a ton of new ways to get points and a new leaderboard. You can read about it all right here and here.

What does this mean for you guys? It means you’ll get some cool new features in the webOS app!

But, not just yet. foursquare’s new API endpoints released in their Android and iPhone apps are still experimental and they’re testing them out in their homegrown apps first. I’ve been talking to foursquare today and I will absolutely be getting access to the new API features very soon (sometime after the start of SXSWi, which is March 11th). Once I get access to the new features, you will be getting them.

They will be in the current (read: Mojo) version of foursquare for webOS, absolutely! I haven’t started on the Enyo version yet, and since I have a 1.4.5 webOS phone, I wanna take part in these new features too!

So, in the meantime, I’ll finish recovering from Mardi Gras and moving into my house and working on incredible! and my new half-secret project. I will definitely be updating you guys as soon as I know something and am allowed to share!

With my recent announcement of my crowdfunding and future plans of incredible! and other apps, I decided to sit down with myself and get some more details about this.

Geoff: So, Zhephree, what prompted you to try crowdfunding incredible!?

Zhephree: well, honestly, it just popped in my head. I knew I’d need new devices and I have no idea how much they will cost, and I just closed on a new house —

G: Oh, congratulations!

Z: Thanks! And, I’m getting married at the end of the year, so yeah, my Taco Bell and gadgets budget kind of got clipped short because of that, so I needed a way to get the new devices. I thought about a straight up PayPal donation setup and just promoting the hell out of it on Twitter and Facebook, but no one pays attention to that. 

G: You think PayPal donations don’t work?

Z: It’s not so much that they don’t work, but there’s no sense of involvement. I have a donation system set up for foursquare, and it’s received a decent amount of donations, but it doesn’t really make people feel like they benefited anything, including themselves.

G: So how does crowdfunding fix that?

Z: People see a progress bar. Seriously, I think that’s a big part of it. It’s fun to check back and go “Whoa! It went up 10 percentage points in 2 hours!” Plus, because crowdfunding sets up a reward system based on how much you pledge, donors literally get something back. For me, since I’m doing this because I’m short on cash, I can’t really afford to give donors much, so I decided to make it fun by offering things like stick figure drawings, or an old shoe.

G: An old shoe?

Z: Only if you pledge over $1000!

G: So, do you think you’ll reach your goal? I think you said in your original blog post that you only get the money if you reach your goal. Is that right?

Z: That’s absolutely right. Crowdfunding is an all-or-nothing situation. If I only raise 99.99% of my goal, I get none of the money and the money is returned to those that pledged it. I have 41 days left to raise the final 17%, so I have a feeling I’ll reach my goal.

G: Do you think this will impact sales of incredible!?

Z: Well, technically, people are buying it right now! This is sort of like pre-ordering the app: pledge money for me to buy new devices and you get the app when it’s done. And since it requires that I raise all of the $1500 goal, it’s sort of like a Groupon — you only get the app if enough people buy into it. But, there’s only been 84 fuelers (pledgers) to hit the $1200 raised so far, so the app still stands to sell more copies. I’m assuming more than the 100 or so people that pledge money will buy the app.  And if more don’t, hey, I’ve got the new hardware to make another app to try and make a hit.

G: It sounds like you’ve thought this out pretty well.

Z: You have to. Just because this isn’t my main job and I work alone, this is still a business. I love writing code and I love doing it for webOS. I don’t want to be pushed away because I couldn’t keep up with the others. I see webOS blowing up within the next 18 months or so and I want to be at the front of the line when new users come in to buy apps.

G: What do you plan to do with any money that goes over your goal?

Z: I plan to divide any overflow between webOS Internals (so they can get new hardware too) and St. Baldricks. I shave my head every year with St. Baldrick’s in solidarity with kids with cancer. The money i raise for shaving my head goes toward youth cancer research. I’ll take a portion of my overflow and donate it. [Ed. Note: You can donate directly to St. Baldrick’s on Zhephree’s behalf here.]

G: We’re running short on time, but I wanted to ask something about your other apps, neato! and foursquare. What are your plans with them?

Z: I’m not abandoning them. Since Mojo apps will run fine on all the new hardware at least through 2011, I’m going to kind of freeze development on them, except for bug fixes. I plan on bringing them to the Enyo framework for new devices eventually, but there’s too many factors to worry about with that. The last major update to foursquare will likely be translations, but that’s still all up in the air and not finalized. Just know that I will not abandon my apps. neato!’s future is dependent on what’s already available on the new devices and what new things are opened up to developers. As of right now, I don’t foresee neato! becoming obsolete.

G: Well, thanks for your time, Zhephree! I look forward to giving incredible! a go! Where can webOS fans pledge money to help out?

Z: Thanks! They can visit RocketHub [http://rockethub.com/projects/1041-incredible-for-webos-lifestreaming-for-the-21st-century]

For those with short attention spans, here’s the TL;DR version:

I am continuing development of incredible!, but I am going to finish the Mojo version quickish to get it in your hands, then build an Enyo version. I need pledges from you guys because I need the new hardware and building the app twice will cut into my freelance web design money. Pledging $5+ gets you the app for “free.”

I’m also freezing features of neato! and foursquare and just issuing bug fixes for them and will port them to Enyo later this year before Mojo support is cut off in newer devices. Any new apps I write will be strictly Enyo.

Here’s the deal: (And if you don’t know what incredible! is, check this PreCentral article)

As a webOS fan, you’ve no doubt heard the latest announcements from HP — three new devices (including a tablet). This all looks amazing!

Another announcement, unfortunately, was made: webOS 2.0 will not be delivered over the air to current users, which means even if HP offers a computer-based upgrade to 2.0 or offers discount vouchers or even free devices for existing users, a lot of users will still be stuck on 1.4.5 (or even 1.4.0 for those in Mexico!).

Another point is that these new devices won’t be out until spring (Veer) and summer (Pre3 and TouchPad). That’s a long time in the tech world.

In addition to new devices, a new development framework was released in alpha (Enyo). Enyo completely changes the game and is a welcomed tool for webOS developers. However, as of right now, Enyo will only be supported on Pre2, Pre3, Veer, and TouchPad. On the other hand, the current framework, Mojo, will be supported for a few months to a year on ALL devices.

SO WHAT ABOUT INCREDIBLE!?

incredible! is about 60% completed and is written in the Mojo framework. This means, if I finish it as is, it’ll run on all webOS devices, even the new ones, but for an indeterminate amount of time. However, because of the uncertainty of the 2.0 issue and because these new devices are still a ways away, I don’t want to jump to Enyo just yet (plus, Enyo’s still only in Alpha).

I do not want to abandon all of the webOS faithful by moving strictly to Enyo and making you wait who knows how many months to use the app. By the same token, I don’t to leave the new devices in the dark once Mojo support vanishes. In addition, incredible! is an app that’s just screaming for more screen real estate, so it absolutely must be tablet-ready.

So, I thought long and hard about this and talked the options over with my fiancée (@zeldamac), and I came to a plan.

THE PLAN

I’ll finish developing incredible! as a Mojo app and get it out there for everyone that’s been waiting and waiting for it. Once a non-beta version is completed, development on the Enyo version of incredible! will begin (or, maybe be developed concurrently).

I know everyone’s been waiting for this app, from foursquare users, to neato! users, to other developers (Inglorious Apps comes to mind), to pretty much the whole staffs at PreCentral and webOSroundup, to Rod Whitby, to a number of Palm/HP employees. And yes, I  did that half-assed name dropping to hype up the app even more.  This app has been touted and hyped about as much as, well, new webOS devices and its release keeps getting pushed back like, well…

I don’t want to leave you guys waiting and I don’t want you to get a crappy version of the app.

WHAT’S THIS HAVE TO DO WITH YOU?

Here’s where you guys come in: this isn’t free. I’ll need new devices for testing and developing, especially a TouchPad. In addition, because I’ll basically be developing incredible! twice, this will severely cut into my freelance web designing, which supplements my income right now. Basically, I’ll be putting that aside to develop incredible! for Mojo and Enyo.

So, because I’ll be missing out on that extra money from freelancing (which, after buying the house, about to get married, I really need… </shameless-guilt-trip>) and because new devices aren’t free, I’ll need some working capital to pull this off and give me incentive to stay awake for 8+ months straight and to take @zeldamac out to eat after I spend way too much time writing code.

So, I’ve set up a RocketHub project for incredible!. If you’re unfamiliar with RocketHub, it’s a website where people can pitch their idea or project and have people “back” the project by throwing money at it. RocketHub is all-or-nothing funding. This means that I only get the money if the goal I set is reached. If the goal falls even $1 short, I get $0 and your credit card never gets charged. It’s exactly like Kickstarter, except they don’t have a silly approval process to post your project.

What’s in it for you? Well, you’ll get the app. There’s also a bunch of various rewards depending on how much you pledge.

Plus, you’ll know you supported an independent developer and webOS. If I’ve got new devices, you can believe more kick-ass webOS apps will come from me.

I know this is a bit unusual, but right now, it’s an idea I had and I hate to let ideas just sit in my head. They get lonely by themselves in there. (THAT’S A JOKE ABOUT HOW EMPTY MY HEAD IS)

WHAT ABOUT YOUR OTHER APPS?

Good question! I am not stopping support for foursquare or neato!. However, I am freezing the feature sets of both apps. This means any foursquare or neato! updates you get will be maintenance and bug fix updates. So, don’t worry — if foursquare or neato! breaks, I’ll fix it in the same amount of time it currently takes me. 

This does mean, however, that down the road I will port foursquare and neato! over to the Enyo framework before support for Mojo apps is pulled from new devices. This is why I am not adding new features to either app. No sense in writing new code that will just have to be rewritten later this year. I don’t want to give a date for when the apps will be ported because, well, I have no idea when Mojo support will be dropped.

As for any new apps (Yep, still got a bunch of ideas for new ones), if I even have the time for those this year, I’ll start those off in Enyo for new devices only. It just makes sense. Sometimes, you have to move on.

WHAT HAPPENS IF YOU MISS YOUR GOAL?

Also a good question. I’m not sure about this yet. We’ll have to see where things go. For now, this is the plan. I’m not sure if it’s a good plan. I’m sure some people will think it’s stupid and think I’m wasting my time, or I’m begging for free money. Who knows, maybe I am. I just want to develop for webOS and having the devices in hand would be a big help.

NOTES

Sure, I can develop without devices, but nothing beats debugging and testing on a real device. My Macbook is far more powerful than any of the new webOS devices, so I won’t know exactly how fast the app is, or if it lags. Plus, the emulator just isn’t 100% exactly like a device.

Also, since if you donate over a certain amount, you get the app anyway without having to buy it later on, you can think of this as a preorder or a “Groupon”.

CLICK HERE TO HELP FUEL INCREDIBLE!

When it comes to webOS, I am first and foremost a user. I bought my Pre in September of 2009 because I liked what I had seen and wanted a good smartphone (Not the HTC Mogul I had before…) Developing wasn’t a thought until almost a month later when I found out about foursquare.

So, as a user, I think yesterday’s announcement from HP were amazing! Amazing hardware, nice OS updates, interoperability between devices — everything is fantastic. I have a Pre Plus on Sprint (Yeah, I swapped the comms board). It works really well for how I use it (E-mail, Twitter, Facebook, some quick photos, texting, light web browsing, and, of course, phone calls. I might fire up Angry Birds every few weeks.) As a user, I’m not what you’d call a “power user”.

I can hang on to my current phone and wait until the Pre3 comes out (whenever that ends up being). I’m in no rush to get a new device (well, I want a Pre3, but I don’t need it yet). I’m also cool with sticking with 1.4.5 on my Pre Plus for the time being. Not too worried about that.

But that’s Geoffrey, the user.

What about Zhephree, the developer?

That’s a great question. So long as I own a current generation webOS device, I will be a webOS developer, even if it’s not on my own network. That’s no issue.

The issue is this new fragmentation that’s been introduced to the ecosystem. (The very thing webOS used to laugh at iOS and Android about…) There are multiple OS versions and resolutions now:

• 320x480 screen with webOS 1.4.x (Pre, Pre Plus)
• 320x400 screen with webOS 1.4.x (Pixi, Pixi Plus)
• 320x480 screen with webOS 2.x (Pre2)
• 320x400 screen with webOS 2.x (Veer)
• 480x800 screen with webOS 2.x (Pre3)
• 1024x768 screen with webOS 3.x (TouchPad)

Obviously, screen res isn’t that big of a deal. If you’re a haflway decent developer, you can account for this very easily.

OS versions wouldn’t normally be a big deal, but, each OS version will support different development frameworks:

• 320x480 screen with webOS 1.4.x (Pre, Pre Plus) - Mojo
• 320x400 screen with webOS 1.4.x (Pixi, Pixi Plus) - Mojo
• 320x480 screen with webOS 2.x (Pre2) - Mojo (for now)/Enyo
• 320x400 screen with webOS 2.x (Veer) - Mojo (for now)/Enyo
• 480x800 screen with webOS 2.x (Pre3) - Mojo (for now)/Enyo
• 1024x768 screen with webOS 3.x (TouchPad) - Mojo (via “emulation”)/Enyo

Obviously, right now Mojo is the most well-supported framework. Right now. Eventually, Pre2+ will no longer support Mojo. This means that eventually, Mojo apps will no longer work on webOS devices. This makes complete sense. Apple did it with OS9 applications on OSX — they supported OS9 applications via emulation for a while, then Leopard came out and killed support for OS9 apps. By then, developers had updated their apps, so it was no big deal.

Obviously, keeping support for legacy apps on newer devices will only drag them down — a chain is only as strong as its weakest link, as they say.

The issue is this: no one has a Veer, Pre3, or a TouchPad, and likely won’t for several months. Very few people have a Pre2. This means the biggest userbase is using a 1.4.x device that only runs Mojo apps. There’s no reason to give up on these users. Continue delivering updates for your Mojo apps.

But for how long? How long until I say “Sorry, foursquare requires a Pre2 or better”? How long before that doesn’t even matter? Do I build an Enyo version that works on newer devices and gets all the new features and just issue bug fixes and maintenance fixes to the Mojo version?

I’m just one guy. I can’t afford to support multiple versions of multiple apps. I have no time for that. 

And what of apps I haven’t finished, like incredible!? Do I keep building the Mojo version of incredible! and release it, and then work on an Enyo version? incredible! is an app that’s basically screaming for a tablet-sized screen, so I HAVE to go Enyo on incredible! at some point. But I barely have time to finish incredible! as it is, let alone maintain TWO versions of it.

So, do I finish incredible! as a Mojo app, get it out there, and as time goes by, make an Enyo version and eventually say “adios” to the Mojo version?

Assuming Palm and HP keep their word (…) and Mojo is supported for the next 10-12 months, that’s enough time to let people upgrade and port my apps over.

However, I just bought a house. I’m getting married in November. I work a full-time 8-5 job, Monday through Friday. I don’t really have the time to do all of this. Do I call it quits on developing? NO, NEVER! But, I may have to resign myself to the fact that others may get apps out before me.

And for ideas like incredible!, I literally can’t afford for that to happen (yes, that’s confirmation that I’ll be charging for incredible!).

Hopefully we get some solid information from HP and Palm soon.

I want to continue to develop for webOS (and I always will, so long as I can afford to own a current-gen device, or can some how wrangle one from Palm, hint hint), right now, I am not totally sure where I should go, in terms of the actual development.

I’d love to have other devs chime in on what they plan to do (assuming you’re sticking around).

With the recent release of foursquare webOS v2.2 (and v2.2.1 today!), you may have noticed you’ve started getting a “You’re a little far away” messages when you check-in sometimes. This is expected behavior.

Using the old API for foursquare, they didn’t force me to supply your GPS position during a check-in. If foursquare’s servers don’t know exactly where you are in relation to the venue, they can’t penalize you.

However, because we’ve switched over to their new API, foursquare now requires me to submit your GPS position on every check-in. The app sends foursquare your latitude, longitude, altitude, your horizontal accuracy (how sure — in meters — your phone is about the latitude and longitude) and your vertical accuracy (how sure — in meters — your phone is of your altitude). So, now that foursquare knows where you are in relation to the venue, it knows if you’re close or far.

For showing up venues in the Nearby list, foursquare uses your position in relation to the point on the globe where the venue is. However, when you check-in foursquare gives you some wiggle room. Different types of venues have a different check-in radius. The check-in radius is the distance from the exact position of the venue that you can be and still be considered at that venue.

For examples, here’s what the check-in radius looks like for the food court on the first floor of my building

As you can see, the red circle shows how far from the center (red marker) you can be from the venue and still earn badges and points.

By contrast, here’s the check-in radius of a local shopping mall, a considerably larger venue:

I actually had to zoom out on the map to show you the size of the circle. The radius here is obviously MUCH larger. For airports, the radius is about twice this size.

This is how foursquare is lenient about your GPS position, since GPS is, unfortunately, not an exact science in mobile devices.

Foursquare also uses the vertical and horizontal accuracies I send them to determine if you’re actually at a venue or not. For instance, if your phone reports a horizontal accuracy of +/- 500m, and your position is 500m away from the ridge of the check-in radius, foursquare will give you the benefit of the doubt that, when adding in the 500m of inaccuracy, you’re inside the radius and they’ll award you any points or badges or mayorships you deserve.

However, lets say that your phone reports an accuracy of +/- 500m and your position is reported as 700m away from the outer ridge of the red circle. Even forgiving 500m, you’d be 200m away from the outer ridge of the check-in radius, and thus you will not be awarded any points, badges, or mayorships.

But, even with all of those levels of forgiveness foursquare factors in, there can still be issues with getting awarded badges, points, or mayorships, even if you’re standing right in front of the venue.

To understand this, you must understand how your phone gets a position. Your phone uses a few things to find your position. The first thing it tries is the GPS receiver inside the phone. To get a GPS lock, your phone needs to find at least 3 satellites in space. The more satellites it finds, the more accurate your position will be. Several real-world obstacles will keep you from finding 3 or more satellites:

• Being inside of a building. In order to find a satellite, your phone needs “line of sight” to the satellite. Think of it like this: you have a flashlight and your friend is sitting on the roof of your house. You go inside the house and point the flashlight up and ask your friend if he can see the light. Obviously he cannot because the light cannot go through the ceiling or roof. If you go outside and aim the flashlight at your friend while he’s on the roof, he’ll be able to see it because nothing is blocking his view. This is (very) basically how GPS works. So, if you are inside of a building, chances are, your phone won’t find enough satellites.
• Being near many tall buildings. If you’re in a downtown area, chances are there are a lot of really tall office buildings. These tall buildings can hinder your phone’s line of sight to the satellites.
• The weather. If there are a lot of clouds or rain, your phone will have trouble “seeing” the satellites and you’ll get bad positions.

What if your phone continually gives you GPS errors? There’s no hard and fast method of correcting this, but this method seems to work (on webOS):

1. Restart your phone. If the app says “GPS is returning Null” or some other error, always try rebooting your phone first. Turn it off, wait at least 60 seconds, and then turn it on again.
2. Force a GPS fix. After your phone has rebooted, open up the Phone app and dial ##477#. This will open a GPS diagnostic app. Tap the “Get Fix” button and wait. If the app shows you a bunch of numbers and info, your GPS is working! If it gives you an error, reboot your phone again.
3. Test another GPS App. After forcing a fix successfully, open another app that uses GPS, like Google Maps. If Google Maps works and shows your position (glowing blue dot), close it and open foursquare. Hopefully it all works!

So, ok, let’s say one of those things happens and your phone can’t get a good true GPS position, then what? Well, your phone has two back-up options, both of which are part of what is called aGPS, or Assisted GPS. aGPS uses cellphone towers and WiFi hotspots to determine your position. How does this work?

There’s a big database (maintained by Google) of tons and tons of known WiFi access points around the world. If your phone’s WiFi is turned on (does NOT need to be connected to a network though!), it can send Google a list of all the nearby WiFi hotspots. Google then knows where those hotspots are and can triangulate your position and give you a rough (no better than 150m accuracy) position.

The same thing also happens using the cellphone towers that make up the cellular network.

However, please note: Verizon (for whatever reason) has blocked third party developers (like me!) from accessing the celltower aGPS features on your Verizon webOS devices. So, if you’re on Verizon and use webOS and your GPS isn’t working, then chances are you will not get a GPS position and foursquare won’t load. One work around is to leave your WiFi turned on (again, it doesn’t need to be connected, just on), which can help a little bit.

So, know you know how your phone finds your position, how foursquare uses that info, and some help with making these things work better. But, you’re probably wondering why the webOS app never had this problem before, but now you have this “Too far away!” message often. Here’s the deal:

Like I mentioned at the beginning of this post: I was actually WRONGLY forgetting to send foursquare your position during a check-in so it couldn’t determine how close or far you were from a venue. I was breaking the rules by doing this. However, the new API forces me to supply this information, so if the foursquare servers think you’re too far, then there really isn’t anything I can do to help.

So, why do this at all? The reason is this: if foursquare doesn’t get your position during a check-in, it can’t see how close or far you are from the venue to which you’re checking-in. If it can’t determine that, theoretically, you could check-in to a coffee shop while you’re at home and steal the mayorship from someone. And what if that coffee shop has a special where the mayor gets a free cup of coffee? Because you got the mayorship of a coffee shop you’ve never been to (or rarely go to), you basically got a free cup of coffee for doing nothing. The specials are designed to award frequent and loyal customers. If you’re not a loyal customer, do you really deserve that free item? Also, it’s kind of lame to do that.

It really is unfortunate that the GPS may not always be accurate, but I personally have yet to see this message ad it’s likely because I always check-in when I’m outside and I leave my WiFi on. And if it doesn’t award you points or badges, it’s ok! It’s just an app. :)