Code Shogun

We all know how hard it is to live in the city while having a car, traffics and all that. But the most frustrating task is to park your car. Enter PrimoSpot: find free on street parking and compare parking garage prices. Search thousands of metro city parking signs for regulations and time left at a parking spot.

You can use the website to plan your trip: finding possible street parking spots, nearby garage hours and fees. And if you ride a bike, find a bike rack there too! You can also download the iPhone app on your iPhone so you can check up parking information wherever you go.

Tonight, I’m here to announce the launch of PrimoSpot Android app, available on the Android Market now! Go check it out! “PrimoSpot Parking” is the app name! Search “Parking” or “PrimoSpot”, you will find it on top of the list! This is THE ONLY app on the market now to help you find parking space!

We have NYC and Boston currently supported, but will expand to other metro cities very soon. There’s also a universal online widget available soon that you can embed in any web pages.

Meanwhile, here are some screen shots of the app in action:

Some Features:
- Uses GPS to find parking information around your current location
- Search entered address to find parking information
- Compare garage prices
- Remember where you parked your car with some reminding notes

Go grab a copy if you live in NYC and Boston and let us know what you think ^_^

Happy Driving!

Android Shogun Android, Mobile, iPhone Android, Boston, iPhone, Market, NYC, parking, primospot

We all know the Palm Pre launch was a big success! I myself picked up the Pre on day one, along w/ a 2-year Sprint contract (weeping…). Merely less than 3 months after its launch, Palm webOS seems to have lost its momentum. Here I will use my own personal experience to write some of my thoughts on webOS in general, and why there’s an uphill battle for Palm to take on going forward.

Underneath webOS lies the embedded linux, much like Android, Nokia Maemo, etc. It’s reliable and proven in the smartphone OS market. On a higher level, Mojo SDK makes up all the high level APIs and frameworks. It mainly uses JavaScript to bridge the low level events/callbacks and high level API, such as GPS coordinates information, accelerometer readings, camera controls, etc. This approach is somewhat like those JavaScript frameworks, such as PhoneGap, http://sourceforge.net/projects/quickconnect/, and Rhodes, where they try to use the common framework built in JavaScript, and uses JavaScript to call underlying low level APIs in the devices, such as Android, iPhone, BlackBerry, etc. This architecture is very cool, but also brings down the performance, comparing to native SDK APIs found in iPhone and Android. For example, the Pre accelerometer is only at 4Hz (4 sample readings per second), comparing to about 100Hz in iPhone. This might be enough for casual usage, but certainly not enough for some serious gaming controls.

By the way, Palm opened Game Developer Cafe to try to lure some game developer on webOS. But without Open GL ES support on the API level (Pre’s hardware is comparable to iPhone, and is capable of running Open GL ES), it’s hard to find serious game developers who want to develop for webOS. You might say you can use canvas in webkit and build game on top of that. Well, canvas performance is still not up to the task, and plus, the current webOS webkit’s implementation of the canvas is not complete. Many essential features are missing, such as reading pixel data.

Mojo and webOS are based on HTML5, CSS, and JavaScript. They are all web standards. That’s where the “web” in the webOS name comes from, right? However, I found this below sentiment troubling. It’s an email from Palm’s product manager:
- Have an appealing design and user interface aligned with Palm UI guidelines and optimized for webOS (i.e., not a “browser” app)

Not a browser app? Are you kidding me? Are you turning your back against your foundation? Apple can rightfully deploy such bind-your-UI-to-my-HIG ‘cuz it’s an Apple product. You Palm is NOT Apple, yet. This is not a way to distinguish yourself. What you should do is to attract as many web developers to your webOS platform as possible. Not creating yet another new system for them to learn. Honestly, there are plenty of guys who can create better UI widgets/elements than the built-in Mojo widgets/elements. Please, Palm, stay to your core value. webOS apps ARE browser apps.

I also heard Palm’s working on virtual on screen keyboard recently. It’s cool and all. But before you doing that, take a look at this article: Virtual Keyboards on iPhone and Android. Please remember, no matter what you do, a virtual keyboard on a 3.1″ screen is never going to match the virtual keyboard on a 3.5″ screen. You just can’t grow the physical screen size.

As to the Mojo framework, my biggest disappointment is the lack of built-in Map API. In order to use Map embedded in your own application, with your custom marker icons and all, you will need to include external AJAX Map APIs, such as Google Map API v2/v3. These APIs work well, but they are not optimized for mobile devices. A Map API is a must for modern mobile OS. Though Apple only recently in their iPhone SDK 3.0 have they included the much needed Map Kit framework. But it works beautifully!

My biggest concern for webOS, however, is its openness of app source codes. Anyone can download the public SDK, enable developer mode on their Pre by entering the classic magic Nintendo cheat code, hookup the Pre with the USB cable, and bang, you have root access on your Pre. There, you can find virtually everything, including source codes for ALL the apps pre-installed and downloaded. Back a few years ago, when most websites were still running on static HTML, I used teleport program to download every single link/page on a given site. It’s messy but it gets the job done. Nowadays, with all these dynamic page scripting and web 2.0 stuff, it’s virtually impossible to get the complete html/css/js codes from any website. With palm webOS, it’s just a click away. Download the app, and there you go, the WHOLE app source codes! In there, you might as well find API Keys used by developers, possibly login information if not coded carefully. I was shocked that Palm didn’t even bother to put in some handy JavaScript compressor and confiscator, such as JSLint and Stunnix JavaScript Obfuscator and Encoder.

This was my big concern before webOS/Pre launch. As a developer, unless my project is open source, I take very careful steps to protect my codes, codes that I write with sweat and blood. Now on webOS, anyone with minimal efforts, can see everything I code up there. This is very discomforting, and Palm MUST address this issue or many developers will unlikely to jump to the webOS bandwagon.

The launch of iPhone 3Gs back in July killed some of webOS/Pre’s momentum. Even though Apple added not many cool features comparing to iPhone 3G. But with a large existing user base and die-hard apple fans everywhere, iPhone 3Gs has been selling extremely well, even in Japan! Meanwhile, Android is on route to be on a bunch of handsets by end of this year. Samsung InstinctQ and HTC Hero on Sprint around October, Motorola Sholes on Verizon, HTC Click on AT&T, G2 myTouch and Motorola Morrison on T-mobile. If Palm cannot address the source code protection issues, if Palm does not launch their second webOS phone (EOS?) by October, we have plenty of reasons to believe the battle against Apple has long been lost. If webOS’s licensing model is not as open and/or flexible as Android so that other handset manufacturers can put it on their own handsets, webOS could very well become a niche mobile OS, a mobile OS we us geeks are fond of hacking and tweaking, but will never reach the status of mainstream modern mobile OS.

Please Palm, do whatever it takes to address these serious issues! I wish Palm webOS best luck, however, the time is not on their side…

Android Shogun Android, BlackBerry, Mobile, Palm webOS, iPhone Android, iPhone, maemo, mojo, palm, pre, webOS

My iPhone app has just won Honorable Mentions from Sunlight Labs Apps For America Contest!
It’s out of a pool of 45 apps/websites ^_^
Here’s the winner announcement and list:
Winner List
Here is how they determined the winner. Looks like Congress Bills are ranked number 11th among all 45 entries. Pretty good considering we did it in our spare time comparing to some relatively large team working on their complete feature-rich websites. In that sense, we are happy about the results. Though I did have some suggestions for the next contest as I replied to their blog:
First, thanks for your all GREAT efforts in making this happen!

I do have suggestions in the next round to have a mobile-specific category. Our app, Congress Bills is an iPhone app. Since it was still during Apple’s review during the judging period, we offered Ad Hoc version of the app providing that judges send their iPhone UUIDs to us. But none of the judges did that. Might be due to the fact that they don’t have iPhones. But the truth is that they had to judge the app purely based on the video on vimeo, screenshots, and blog descriptions. Since the mobile device is a very different kind of media than website, there are unique features/advantages exhibited from them. It’s sad that the the app did not get a complete look (from our opinion) to be rated.

We are also having an Android version of the app running btw.

I would suggest that in the next contest, state whether you will have sufficient resources in judging mobile applications. Resources such as the availability of the mobile phones, and the models of them. Since the contest rules said any platform, I was actually thinking of building a robot that can etch laser on the wall showing the current activities of the congressmen. Oh well, that went a bit too far

Thanks again!

*It’s an open source iPhone app with LAMP backend. I will update more on details later…

iPhone Mobile, iPhone congress bills, contest, iPhone, open source, sunlight, winner

Gesture/Motion-based detection is fast becoming an integral part of many mobile applications.

One neat usage of it is to shake to erease.  The first one I’ve encountered is SketchUp from the early days of jailbreak iPhone.  Then there are shake to delete done-items on your todo/shopping list, etc.

There are many approaches to detect shake motion, one is from ClingMarks.  Basically it calculates the total delta (changes) in all 3 axises: x, y and z between the current even time and the previous one, and divide by the time elapsed to find its psudo-velocity.  (I call it psudo because it’s not actually a velocity in any direction; it’s more like a mixed-up velocity from 3 axises).  If this velocity is greater than a pre-defined threshold, it’s been viewed as a shake motion.

From the code point of view, you need to implement the SensorListener:

public class ShakeActivity extends Activity implements SensorListener


You will need to acquire a SensorManager:

sensorMgr = (SensorManager) getSystemService(SENSOR_SERVICE);


And register this sensor with desired flags:

ensorMgr.registerListener(this,
SensorManager.SENSOR_ACCELEROMETER,
SensorManager.SENSOR_DELAY_GAME);


In your onSensorChange() method, you determine whether it’s a shake or not:

public void onSensorChanged(int sensor, float[] values) {
if (sensor == SensorManager.SENSOR_ACCELEROMETER) {
long curTime = System.currentTimeMillis();
// only allow one update every 100ms.
if ((curTime - lastUpdate) > 100) {
long diffTime = (curTime - lastUpdate);
lastUpdate = curTime;

x = values[SensorManager.DATA_X];
y = values[SensorManager.DATA_Y];
z = values[SensorManager.DATA_Z];

float speed = Math.abs(x+y+z – last_x – last_y – last_z) / diffTime * 10000;

if (speed > SHAKE_THRESHOLD) {
Log.d(“sensor”, “shake detected w/ speed: ” + speed);
Toast.makeText(this, “shake detected w/ speed: ” + speed, Toast.LENGTH_SHORT).show();
}
last_x = x;
last_y = y;
last_z = z;
}
}
}

The shake threshold is defined as:

private static final int SHAKE_THRESHOLD = 800;


This is pretty straightforward. So if your app just simply needs a shake motion detection, w/o needing to know on which direction it’s shaken, this code is good enough. However, there are situations where a non-shake motion would be detected as shake due to the fact that the formula is not actually the correct or should I say a precise formula for determining the shake motion. I call this a coarse-grain approach.

In my next post, I will show you a more fine-grain approach, something I learned from iPhone SDK programming

You can download this sample here

Happy Coding!

Android Shogun Android, Mobile, iPhone Android, iPhone, motion, shake