Google Android

mikelove

皇帝
Staff member
Interesting (as that article notes) how many of these are made by HTC - really makes me want them to buy Palm, actually. Not just for ha-ha-if-HTC-buys-Palm-maybe-they'll-make-fewer-Android-phones reasons, though that certainly might be a fun added benefit, but because nobody seems to be going after the large number of consumers who still buy BlackBerry devices; we get far more BlackBerry emails than Android ones at Pleco even now, and while I'm sure there are one or two obscure keyboard-on-the-front Android phones floating around somewhere, there definitely don't seem to be any that are widely-used. But combine HTC's hardware-engineering and carrier-gladhanding prowess with Palm's wonderful OS and their stack of mobile keyboard patents (those are the real gems, the countersuing-Apple ones would be much harder to use given that a lot of them originated from ex-Newton engineers) and you could finally have a true BlackBerry rival.

Looks like Dell's upcoming Android tablets have had a bit of a design change, though since the iPad-rival 10" one isn't supposed to be out until 2011 I still don't think they're likely to be a major factor.

The size of the enthusiast community for Android isn't actually that much of a selling point - if everyone who made a whiny reddit comment about getting rid of their iPhone and buying a Nexus One actually did so, Google wouldn't need to make all of their money from search advertising anymore. The real question with Pleco for Android market-wise (particularly as it fights for our attention with a desktop version) is whether it'll allow us to reach out to whole groups of customers we wouldn't be able to get at with iPhone / iPad; if Android simply offers the same user base but more of them, that's not a recipe for really growing the size of Pleco that much, at least not in the way a desktop or web-based version potentially might.

Something that would also help on that front would be making Pleco more streamlined and easier to use, which is probably our biggest single post-flashcard-version priority; another major reason not to rush right out and port to Android is that we'd be porting over a design from iPhone that we're still not really happy with. Particularly given the difficulty of synchronizing updates between versions, we're much better off if the thing we're porting over is a mature, thoroughly-polished product.
 

numble

状元
mikelove said:
Something that would also help on that front would be making Pleco more streamlined and easier to use, which is probably our biggest single post-flashcard-version priority; another major reason not to rush right out and port to Android is that we'd be porting over a design from iPhone that we're still not really happy with. Particularly given the difficulty of synchronizing updates between versions, we're much better off if the thing we're porting over is a mature, thoroughly-polished product.
I agree with this. I look at iPad apps like 1password, and it just feels like the app is an extension of the OS, even down to their program specific icons mimicking iPhone icons, and other apps utilize swiping between sections as a navigational element which seem to be more prevalent in the iPad system. I just find things very functional in Pleco, but not the most aesthetically pleasing or intuitively designed.
 
Out of interest, how does the update process work now that Pleco supports the iPad?

I mean, is it the same package you upload to the AppStore that is downloaded by both iPad and iPhone users? or do you upload a separate one for each?
 

mikelove

皇帝
Staff member
westmeadboy - in our case, it's just one package, running the same code; we add a flag to our application's Info.plist saying that it's been optimized for iPad, then add iPad-specific checks / code segments anywhere they're needed. (though most of the UI auto-resized without needing any changes once we added that flag)

It's possible to make two different versions, however, and many developers - especially game ones - have used this as an excuse to totally redesign their apps for separately-sold iPad-only "HD" versions. In Pleco's case, since we're so licensed-content-heavy it would be kind of creepy of us to charge separately for an iPad-optimized version of that same content (it'd be as irritating as having to pay full price for Blu-Ray versions of all of the films you just bought on DVD a few years ago), but with $2 apps that consist of little other than their UIs it's quite reasonable, particularly given the relative sizes of the tablet and smartphone markets.
 
Thanks Mike.

If the codebases were significantly differently then, as a developer, you'd probably want to distribute two packages anyway. Otherwise you could often have the situation where you release an update to fix, say, an iPad bug but nothing would appear different to the iPhone user. So the iPhone user has been bothered for no reason (also could have accidentally introduced an iPhone bug in the process!). More importantly, each update you would have to be tested on both iPad and iPhone.

If its just a few UI tweaks here and there, then one package would be the way forward.

On Android, thanks to the lack of proper support for in-app purchases, I maintain a free and a paid version of the same app. Two separate packages, two completely separate entries in the Android market. I develop/maintain one package locally but during deployment create two packages from that. To do that, there are just a few steps (not automated) I have to go through which are relatively painless but have to be absolutely certain of getting it right. Not really optimal!
 

mikelove

皇帝
Staff member
Honestly, I'm not that big a fan of Apple's in-app purchase system; I love the fact that it exists in general, since it's much better than having to sell one immutable app, but it doesn't allow for the sort of flexibility that one needs to really treat customers well; cancelations / refunds have to be processed through Apple, there's no way to credit someone's previous purchase towards the purchase of an upgrade or "bundle" without a whole lot of complicated logic / extra catalog items, etc.

So if Google wants to "get this right," I'd hope they'd do something that more straightforwardly linked to a Google Checkout account - let developers calculate the pricing however they want in-app rather than using static catalog items. Google can still get their commission (a commission that I very much hope would be less than Apple's 30%), since the sales are all going through a system they control, but developers can handle pricing / upgrades / single-copy-on-multiple-devices however they see fit. Even better would be a Google Checkout library that would also work with in non-Market apps with only a standard Google Checkout fee and no commission, though that seems very unlikely to happen.

(Seriously, if Google wants to beat Apple so badly then why do they charge 30% commissions anyway? Charging just credit card fees + 1-2% for "processing costs" would make developers more money -> lower the cost of Android software for users -> vastly increase their numbers of both, and Apple couldn't counter it since the music companies / movie companies / publishers et al that also sell through iTunes would immediately demand the same discount if they did.)
 
Why 30%? I think its a carrot for the carriers. A way to tempt them to push Android devices.

The Android Market is the single area I'm not happy with in the Android world. I could write pages of stuff about improvements I'd like to see, but...well, I won't :)

AFAIK, the Android Market 30% goes to the carriers. But what if you are connecting over WiFi on an unlocked device you bought directly from Google? Doesn't matter, it still goes to the carrier. But what if I take the sim card out completely, how will they know which carrier to credit? Then you won't see paid apps on the Market so won't be able to buy them...until you put a sim card back in.

As someone who uses the Market exclusively over WiFi this really annoys me. I use my HTC Hero as a test device and leave a 5-year-old sim card in there just so I can see paid apps.

This might go some way to explaining why only a few countries are supported for purchasing paid apps. Canada was only added a couple of weeks ago. Japan is the only Asian country :(

Not sure how this works for tablets that often don't use sim cards.

I don't understand why they don't give the commission to whoever they sign the deal with to put the Market app on the device. So if I buy direct from HTC, it goes to them. If I buy on contract from T-mobile it goes to them etc
 

mikelove

皇帝
Staff member
Interesting - I'm embarrassed to say I had no idea the carriers were getting most of that money. Makes me less worried about the possibility of carrier-specific markets - why would they bother? - but at the same time, more worried about the possibility of other carriers following AT&T's lead in disabling the use of non-Market apps, since there's a much more tangible reason than "security" or "network usage" to do so.

It occurs to me, though, that since Google has little or no financial stake in whether people buy inside or outside of Android Market, and since they don't have to re-approve application updates, and since being kicked out of Android Market isn't quite the crippling financial blow that it is on iPhone, one might be able to get away with flouting their rules and distributing a free app in Android Market with its own, non-Google system for selling add-ons. Have you ever heard of an app actually being rejected and/or kicked out of Android Market for doing that? (I personally have no ethical problem whatsoever with that, it's just a question of whether or not one can safely get away with it, and on iPhone unfortunately one can't)
 
I don't actually think that is against the rules. All they say is that any charge you make for a product distributed through the Market, must be charged through the Market. You could argue that Add-Ons downloaded via the internet have not been distributed through the Market...

I suppose its like the Amazon app which is free and but Google don't get 30% of each mp3 download!
 

mikelove

皇帝
Staff member
From http://www.android.com/us/developer-distribution-agreement.html:

3.3 You may also choose to distribute Products for free. If the Product is free, you will not be charged a Transaction Fee. You may not collect future charges from users for copies of the Products that those users were initially allowed to download for free. This is not intended to prevent distribution of free trial versions of the Product with an “upsell” option to obtain the full version of the Product: Such free trials for Products are encouraged. However, if you want to collect fees after the free trial expires, you must collect all fees for the full version of the Product through the Payment Processor on the Market. In this Agreement, “free” means there are no charges or fees of any kind for use of the Product. All fees received by Developers for Products distributed via the Market must be processed by the Market’s Payment Processor.

The question would be how one interprets the idea of an "add-on," I guess. In Pleco's case, since we're unlocking additional functionality and not just data files, it would be tough to argue we were doing quite the same thing that Amazon does. (though I wouldn't be surprised if Amazon is tithing some of their Android sales to Google / the carriers too)
 
That suggests you could sell for $0.01 and then only unlock the full features if they pay the full amount (through your own payment processor)!

Loophole maybe? Maybe not, if you just read the last line by itself.

But yes, the way I read it is that you can't charge (outside) for unlocked features but you can charge for stuff downloaded separately.
 

mikelove

皇帝
Staff member
The ambiguity would be useful if one were actually to try this - as long as you can argue that it's not clearly against Google's rules, which it doesn't seem to be, then in the event that your app was pulled, if it was a popular app it could create a PR nightmare for Google; lots of unflattering comparisons to iTunes would emerge. Which they obviously don't want - IIRC there was a pretty big kerfuffle even when they pulled a clearly buggy / defective app at one point - so it makes it much less likely they'd actually pull the trigger on it. I don't know if I'd want to be the first app to do this, though...
 

numble

状元
mikelove said:
Honestly, I'm not that big a fan of Apple's in-app purchase system; I love the fact that it exists in general, since it's much better than having to sell one immutable app, but it doesn't allow for the sort of flexibility that one needs to really treat customers well; cancelations / refunds have to be processed through Apple, there's no way to credit someone's previous purchase towards the purchase of an upgrade or "bundle" without a whole lot of complicated logic / extra catalog items, etc.
How are Apps like Kindle, WSJ, and Zinio allowed to run purchases outside the iTunes system? I know Kindle and Zinio pop you out to Mobile Safari, but WSJ let's you register and input your credit card info inside the app.
 

variety

Member
So, having read back in this thread a bit and a half I'm still not sure if anyone is working on an Android port or not. What I do know, however, is that you haven't mentioned the most important reason: I just bought myself a HTC Desire, and crave some Pleco love. Great devise :), great OS ;), no Pleco in sight :(

What's the chance of having that situation remedied before summer's end?
 

mikelove

皇帝
Staff member
numble - there seems to be some sort of complicated backroom deal with Apple involved in those cases; according to the now-publicly-disclosed distribution agreement you can do it with Apple's express written permission, but I've never heard of anyone actually getting that permission.

variety - the chances of an Android version before summer's end are very slim - the "Pleco Lite" Android project I mentioned a few pages ago could probably be done by then if we decided to go ahead with it right away, but whether that or a desktop version is our next project is still up in the air; depends a good deal on a customer survey we're planning to do in conjunction with the next version update.

And since there's a distinct possibility that we might start work on an Android version only to realize it would be way more work than we expected and have to table it for a while, it's unlikely we'll actually announce any Android version of Pleco until it's almost ready to release.
 
Mike,
As one of your biggest fans, and a big time pusher of Pleco (I've already referred several people), you know I want to take the greatest of care when I make a suggestion to you. I've been reading this thread for a long time, and there's just some things that keep getting said that are eating at me too much.
----
1 Many of us, absolutely do make our smart phone platform choice based on what will run Pleco. Definitely. The ONLY reason I don't own a Nexus One is Pleco.

2 While you used pointer math to make Pleco fast (naughty but necessary a few years ago) it's imprisoned Pleco to some extent and you're going to eventually have to recode that part no matter what. The C# code and the Java code then look awfully similar.

3 Dictionaries are not functionality, they are books. You should have no trouble with the Android market because your application is a super sophisticated book reader. The ability to license book titles to be read in your super reader seems scarcely different from what an Amazon book app would do.

4 I don't need or want Pleco on my desktop. (sorry :( )

5 My colleagues and I LOVE Pleco because the dictionaries are OFFLINE. An online version wouldn't exist to us.

6 I need an upgrade path from my HTC HD which is great but aging. Iphone is like selling myself into indentured servitude. Together with four other Pleco users sitting next to me, please register my support for Pleco Android.

Rob
 

mfcb

状元
RobRedbeard,
agree with most of your points, especially #5.
i think, for all the people still using WM it would be best if mike goes for the windows version first. here is my reasoning:
- mike frequently mentioned, that the windows version is just "little" work to port over from WM.
- that makes me think, that the WM version could in that way have some of the extended functionality put into the windows version back the same route (like improved reader...)
- there are also portable devices running windows, i find the name "desktop version" to be a little bit misleading...
- in the future there might be many more portable windows devices, maybe even phones...
- after the windows version is done, mike might have a much clearer look at the android fragmentation situation.
 

mikelove

皇帝
Staff member
RobRedbeard - very true on #2, since WP7 doesn't allow for the use of unsafe mode.

Once again, though, the fact that your justification for wanting an Android version has to do with an aspect of iPhone (the "indentured servitude") that, to be honest, the vast majority of consumers don't care about worries me about about whether we'd really be growing the size of our potential market much with an Android port. The computer-savvy types who are responsible for most of the posts in this thread are among our best customers, but there simply aren't enough of you to make Pleco successful on your own; people learning Chinese overall are not AFAIK more proficient with technology than the general population, and simply owning a PDA or smartphone is no longer as geeky as it was in the early days of Pleco.

This also hurts the case for a "Pleco Lite" for Android, I guess, since the very same subset of Pleco users who are most interested in an Android port also happens to be the subset that's most interested in the sorts of complex / arcane features that are likely to be the last ones ported over. Given that we've already gone to the trouble of designing / creating those features, I suppose we might want to just accept our "Chinese dictionaries for computer nerds" label and proceed from there, but the time / resources we might put into a "full" Android port could also be put into thoroughly shedding that label on iPhone, maybe even rolling out alternate iPhone products like something with a highly slimmed-down interface that involved just a single purchase and had all of its data files built-in, and/or to developing a desktop or web-based product that might arguably be a better home for those sorts of complicated features anyway.

The fundamental problem is this: while we're selling a lot more copies of our software now, our margins are a lot lower on iPhone than on Palm / WM (hardly a big secret - we're charging less for things and yet paying Apple a 30% commission), and hence we're not seeing the sort of giant leap in our revenues that we might have hoped for with an iPhone version. The low margins are basically a fact of life in the modern smartphone market; consumer unwillingness to pay high prices is if anything an even bigger problem on Android, and I'm not at all confident we could avoid the commissions either if companies like AT&T can get away with blocking non-Market apps with hardly anyone complaining. And the prices we can charge may slip even further as the quality of free / low-cost alternatives continues to improve. Heck, Android's easier inter-app communication makes that even more of a problem than on iPhone; you don't need to build flashcards into your free Chinese dictionary on Android, you just link your dictionary to the free Android version of Anki.

Putting many / most of our resources towards an Android port right now would represent a sort of doubling-down on our current business model, putting the same product you all have loved for years on yet another platform you've temporarily alighted on, continuing to be largely uncontested in the high-end mobile Chinese dictionary market but also continuing to address through that only a very small subset of the overall Chinese learning community. While pretty much every other alternative (even just putting everything towards iPhone improvements) would have more potential to let us branch out, maybe even hit a point size-wise where we'd be able to start working on a bunch of projects (like an Android port) simultaneously. And I'm really not worried about a Pleco-level product appearing on Android on the meantime - a high-end Android Chinese dictionary is an even less promising prospect financially for someone starting from scratch.

If we can overcome the fragmentation concerns, developing an Android version next is probably the safest move, both because it's something we already know there's a market for and because it would protect us against any future mischief from Apple, but that doesn't mean it's the right one, or the one that's best for our users long-term.

mfcb - good points, though a lot of the cool things about the desktop version might unfortunately be difficult to port back to WM (even assuming that WM sales hold up enough post-iPhone-flashcards-and-Windows-Phone-7 to justify it). Going forward, though, particularly if WP7 is less than a slam-dunk I could see Microsoft coming at this problem from another direction and scaling down desktop Windows to work on ever-smaller devices - Intel with Atom is shrinking X86 processors to the point where it almost makes sense to put them into smartphones - so the desktop-doesn't-mean-desktop argument could get even stronger with time.

radioman - that is interesting; haven't seen many people arguing for iPhone's restricted-ness from a corporate IT perspective, but it makes sense. Though at the same time it's quite possible some handset vendor (maybe RIM if they finally give up on their ever-more-outdated-seeming OS) might eventually carve out a nice little niche for themselves selling locked-down, corporate-friendly Android devices; certainly possible to take it in that direction, though given all of the customization involved, those devices definitely wouldn't be getting regular updates to the latest OS versions...
 
Top