Google Android

[mikelove]

The problem with these sorts of systems is that they generally only work if you're playing nice and using the built-in UI controls - with the sort of elaborate custom interfaces we use in Pleco, it would be almost impossible for any built-in UI rearranging system to set things up correctly.

 

[westmeadboy]

China Mobile opts for Android:

http://www.itproportal.com/articles/200 ... e-network/

I don't know if anyone's finding these links interesting - if not, then please let me know and I will stop!

 

[Andy]

I think a stand alone Pleco dictionary is a great idea. When I first found out about Pleco, I had never really used a PDA, but the electronic dictionaries I had used to that point had been all designed for native Chinese learning English. I bought a Palm T3 just to run the program and later a WM phone. Before I bought these, I had to research which devices were most appropriate to buy and lay out the cash to buy them. Afterward, I had to learn to install the programs on the devices. This doesn't seem like that much effort to most of us, since we use these things everyday (and I'd be lost now without a pda phone), but to someone like my dad all of this would be too much of a time/money investment just to get a dictionary.

I see quite a few people paying hundreds of dollars for stand alone electronic dictionaries that don't have nearly as many usable features as Pleco, or that have Chinese UIs that seemed navigable when the sales girl at Wangfujing Bookstore showed it to them, but now sit on a shelf. As soon as I started using it i didn't know how I had managed without it, and showed Pleco to all my classmates, but only a couple of them bought it, and they were people who were already using mobile devices.

I've yet to see any electronic dictionary that's as usable to an English speaker learning Chinese as pleco is, I think the market for a stand alone dictionary would be larger than the iphone market, which itself could promise to be larger than that for palm and Windows Mobile combined.

 

[mikelove]

A standalone dictionary is certainly something we'd like to do, but it's fairly capital-intensive (even if the hardware's just a reference design we still need to build many thousands of the things up-front to get a decent price) so not something we're quite in a position to do yet. We are thinking about finally selling Pleco on SD cards, though, since that would cut out most of the installation difficulties (even unlocking, since the keyfile would be Card-ID-based and installed right on the card) and would also allow us to offer a more generous return policy.

 

[westmeadboy]

Oh, this would be nice - Android netbooks! meaning potentially you could run the same app on your netbook as on your smartphone (license-permitting of course).

"Our source confirmed that many different Android netbooks, as well as other Android-based projects are in the works. And that China is a hotbed for Android-based activity right now."

http://venturebeat.com/2009/02/09/apple ... -complied/

More details here:

http://venturebeat.com/2009/01/01/andro ... y-by-2010/

What I like about this, is that I find lengthy flashcard session on a small screen to be very tiring on the eyes. Being able to do more stuff on a netbook size screen would be much better. The look and feel would be very similar, which is pretty important, I think.

 

[mikelove]

Nice, but I'm still turned off by the Java-only nature of Android - I keep hoping the renaissance in mobile gaming taking place on iPhone will be enough to push Google to open things up to native C development, but it hasn't happened yet. Perhaps the move to netbooks and a desire to take advantage of the dizzying array of native Linux applications will finally force them to make that switch - otherwise I think they'll lose out to Windows 7 and the inevitable iNetBook (or iEee, which I just realized sounds like 阿姨).

 

[character]

Nice, but I'm still turned off by the Java-only nature of Android [...]

Have you thought about pointing one of your more open-minded :wink: developers at Eclipse and the Android plugin for it, giving that person a month and seeing how far they get? You might be surprised.

In a weekend I cobbled together a simple C-E dictionary based on CEDICT for Android. I'd much rather just buy Pleco, but with over a decade of Java experience, in my spare time I can make all the Chinese learning programs I need now that I have an easy-to-develop-for mobile platform.

http://pragprog.com/titles/eband/hello-android
http://developer.android.com/
http://www.droiddraw.org/
http://code.google.com/android/groups.html
http://planetandroid.org/
http://www.engadget.com/tag/android/

 

[mikelove]

I think you're overestimating our programming resources a bit But more practically, anything we can do in a month, someone else can do in a month too; putting a simple Unicode-friendly search UI on top of a SQLite database is pretty darn easy, that's why there are about a dozen nearly-identical CEDICT-based Chinese dictionaries for iPhone that consist of exactly that, and I'm sure a few for Android too. Simply doing something like that with our higher-quality licensed content isn't a possibility because of sales / copy-protection concerns; when all's said and done I think we'll have spent as much time on that aspect of the iPhone port as we will have spent on the actual dictionary part (though a lot of that has to do with the downloading of add-on databases rather than the actual copy-protection stuff).

And Java support isn't just a matter of the initial port, it's the maintenance too - every time we write a new feature we'd now be writing it twice, once in C and once in Java. Whereas our WM / iPhone / eventual desktop versions can all share that same nice friendly C core - if we add some cool new flashcard option it'd take just a few lines of code on each platform to add the checkbox that enables it. Even if Microsoft switches to .NET-only applications in Windows Mobile 8, as it's rumored they'll do, it's a lot less work to get our code switched over to C# than it is to rewrite the whole thing from the ground up in Java.

I hate hate hate hate ports, as I've mentioned here a few times in the past - for me the ideal number of platforms to put Pleco on is 1. The desktop version is an exception since it actually enables people to do things they can't do on mobiles, but spending massive amounts of time and money just to reproduce the exact same functionality we already had working on last year's must-have phone on this year's must-have phone is something that bugs the heck out of me. When Palm started falling behind Microsoft we had to branch out to Windows Mobile, and now that Microsoft's falling behind Apple we have to branch out to iPhone, but hopefully by the time Apple starts falling behind Google, web-based mobile applications will be practical / well-accepted enough that we can make the move to those and never have to worry about rewriting Pleco on another new platform again.

Platform choice may be great for consumers but it's awful for developers - if someone comes in and takes over 90% of the mobile OS market like Microsoft did on desktops I will be jumping for joy.

 

[character]

I think you're overestimating our programming resources a bit

Sorry, perhaps you were using the royal we in messages where you talked about what was happening during the development of Pleco 2.0.

But more practically, anything we can do in a month, someone else can do in a month too [...]

Really? I wasn't aware you made your source code available to others to port. You would be starting well ahead of anyone else because of your existing algorithms.

putting a simple Unicode-friendly search UI on top of a SQLite database is pretty darn easy, that's why there are about a dozen nearly-identical CEDICT-based Chinese dictionaries for iPhone that consist of exactly that, and I'm sure a few for Android too.

Oddly enough, they're aren't any for the Android. I don't know if people were waiting to charge for their apps (which just started). Given license restrictions, I think some of the stuff I'm going to write will be free.

And Java support isn't just a matter of the initial port, it's the maintenance too - every time we write a new feature we'd now be writing it twice, once in C and once in Java.

I know. I would just prefer to spend my spare time learning Chinese using Pleco instead of writing Android apps.

All that said, looking at the iPhone threads, I guess you are moving well along on that front. I'm not opposed to picking up a iPod Touch to use Pleco; I just hope you have some way to transfer my WM license over at minimal cost.

 

[mikelove]

Well it wasn't 100% me, but I was certainly doing an awful lot of the coding

Our algorithms rely heavily on some things like pointer arithmetic that don't really have any good equivalent in Java - rewriting them would take almost as long as starting over from scratch, and the results would likely be neither pretty nor particularly inefficient. And anyway we'd get better performance using SQLite, since Android at least has a native-code version of that - SQLite-based dictionaries in Pleco 2.0 are slower than our proprietary ones in large part because we wanted to make them compact and easy to edit, but we could develop something with a bunch of extremely-slow-to-rebuild custom indexes that would perform almost as well as our proprietary databases on Palm / WM (and better than anything we could write in Java). That would take a lot more than a month, though, particularly when you add in encryption and data compression.

I'm not 100% shutting the door on an Android version, but unless the market share argument gets to be truly overwhelming (or some other tragedy strikes, like Apple permanently and unequivocally rejecting our iPhone app) I'm not writing it myself, so if we do develop one it'll either be because the iPhone version is a colossal money-making blockbuster or because a VC shows up at my door with a dump truck full of money and very little expectation of control Interesting to hear that nobody else has released a Chinese dictionary for Android yet, but given all of the talk of Chinese phone manufacturers embracing Android I can't imagine that'll last very long.

 

[character]

Interesting to hear that nobody else has released a Chinese dictionary for Android yet, but given all of the talk of Chinese phone manufacturers embracing Android I can't imagine that'll last very long.

I double-checked. Just to be clear, there are a couple multi-language dictionaries which purport to have Chinese, and a couple of CE dictionaries which require a bunch of steps to assemble all the parts they need, but I didn't see any explicitly based on CEDICT on the market. There are a number of Chinese apps (soft keyboards, IM clients, etc.) on the market as well.

 

[mikelove]

Interesting - I still think this is bound to change, though, in particular given the poor download numbers for a lot of Chinese dictionaries in the now-very-crowded iTunes store. If Pleco were starting from scratch and didn't already have an established brand / people writing us every day asking for an iPhone verison, I think we might have stayed away from iPhone ourselves; a few developers are getting rich off of iPhone software, but most of them aren't, and it's very tough for a new app to get much interest if people aren't actively looking for it.

 

[westmeadboy]

Here's a bit more about Android coming to netbooks and desktops:

http://www.techradar.com/news/software/ ... eat-541842
http://www.bloomberg.com/apps/news?pid= ... 70KzBQtm_U

One very good thing about Android is that it makes it really easy for applications to interoperate. I think this is something particularly useful for some thing like Pleco - which you may want to plug into other applications.

 

[mikelove]

Interesting, but again I'd really like to see them support native development - Java's neither well-designed enough nor fast enough to be the only way to write software, particularly not for a desktop OS.

 

[character]

Interesting, but again I'd really like to see them support native development - Java's neither well-designed enough nor fast enough to be the only way to write software, particularly not for a desktop OS.

That may be the case (it would be nice to see current evidence), but there's no reason I can think of that Pleco couldn't be rewritten into a nice OO Java app. It's your prerogative to stick with C, of course.

IIRC, the "Java is slow" came from the early days of Java, when PCs were ~90-200MHz. Now phones are faster than that, never mind PCs, and a lot of knowledge has been gained about how to speed up VM-based languages such as Java. It's certainly possible to write slow programs in any language; for Java books such as Java Platform Performance and Effective Java are helpful for understanding how to best use the language.

A big reason you don't see a lot of Java on the desktop (besides Eclipse-based programs) is that Java grew up during the Internet age, so a lot of development focus in general has been on server-side web programming. It hasn't helped that both MS and Apple have had spats with Sun/Java over the years, and Java wasn't open source until recently, which hurt it with Linux distro makers.

 

[mikelove]

There's quite a lot of low-level code in Pleco that would be hard to replicate in Java. I mentioned the database system before, but that at least we could theoretically reproduce if we rewrote it from scratch to not use pointers / other Java-unfriendly things. Even harder would be the custom blitter (for anyone else reading this, a blitter is a bit of code that copies images from one location in memory to another) we use for font rendering (both on Palm and WM) - I don't know how you'd even go about writing a decent blitter in Java. We're trying to make do with the built-in font rendering on iPhone, but while the performance is decent enough that we can use it in the first release we're almost certainly going to need to replace it with our own code eventually, and I have no reason to think Android would be any better on that front.

But my anti-Java bias isn't even the main problem here, it's my hatred of ports and the iffy economics of Pleco's doing them. The latter could be turned around if the iPhone version proves to be a breakout for us sales-wise, since that would show that there are a lot of people out there who haven't bought Pleco but would if it supported a platform they like (not the case with Windows Mobile, which has gradually devoured most of our former Palm sales but hasn't actually caused much growth), but the former is still a problem and even if we were flush with cash from iPhone I don't know if I'd want to spend it on an Android version when there are other, more original / interesting things we can work on.

 

[character]

There's quite a lot of low-level code in Pleco that would be hard to replicate in Java.

I'm not sure why you would want to, assuming :wink: an acceptable level of performance could be had with the provided libraries and your own well-written Java code.

I'm not a performance expert, though I have read a number of Java performance books and done some optimization. Some things to consider when writing Java:
- Leverage existing libraries which are probably implemented in optimized native code.
- Code which isn't there runs infinitely fast. This is the old saw about avoiding operations which are unnecessary, such as loading all elements of a list when only the first 10 will be shown to the user. It has some collaries:
-- Avoid creating unnecessary objects.
-- Reuse objects. Don't create 1000 complex objects if only 10 at a time are shown to the user; instead, have an object pool from which an object can be pulled, populated it with values, and used.
-- Avoid making code thread safe if it doesn't need to be.

But my anti-Java bias isn't even the main problem here, it's my hatred of ports and the iffy economics of Pleco's doing them.

Your hatred of ports is certainly understandable. You might dislike Java less if you compared it to the complexity of C++ (where I've seen coders spend half their time arguing about what their program is supposed to do, and half their time arguing about how C++ works). Object orientation is just a useful paradigm which among other things lets one map the real world problem domain onto objects in code. Having worked in C and C++, I find Java a good middle ground between the two, and much more productive to work in than either.

The latter could be turned around if the iPhone version proves to be a breakout for us sales-wise, since that would show that there are a lot of people out there who haven't bought Pleco but would if it supported a platform they like (not the case with Windows Mobile, which has gradually devoured most of our former Palm sales but hasn't actually caused much growth) [....]

My guess is that the iPhone version won't radically increase your overall customer numbers (nor would an Android version, for that matter) so you should charge a premium for the iPhone version to make it worth your while. Maybe take the Wenlin approach and charge $200 for most users, with a discounted academic version.

 

[mikelove]

Given the amount of time we've spent hacking around bugs / limitations / badly-implemented parts of Palm OS, Windows Mobile, and iPhone OS, I have a hard time believing that Android is so polished as to make it possible to do whatever we want with built-in APIs, so I wouldn't launch an Android port without assuming there were going to be at least a couple of things which the OS was supposed to do for us that we'd end up needing to reimplement on our own, and that makes the performance of low-level code a major concern.

The interesting Pleco code is all written not in C++ but in plain old C - I for one am so comfortable with that that I use it even for things it's extremely bad at, like text processing. Our "FounderPounder" utility for converting Founder-format prepress data to usable text files is written in C, for example, in spite of the fact that most people would write such a thing in Perl or another text-processing-friendly language.

I disagree with you about iPhone pricing, though - there's no way we could charge $200 for even a highly-specialized piece of iPhone software like Pleco. I do think prices in AppStore are going to go up from their current $1/$2 level once the more complicated apps people have been working on for the past year start to appear - we're not the only mobile developer taking our time about iPhone support - but $200 just won't fly.

And with Chinese learning on the rise I see iPhone as a way to make Pleco a bit more mass-market than we are now - for a lot of people an iPhone version of Pleco is basically cutting the cost of entry by 75% by eliminating the need to get a $300 phone/PDA, not to mention the fact that since the iPhone version should be much easier to install than the Palm / WM ones it'll be a lot more accessible to non-technical users, so combining that with the considerably more straightforward user interface (now down to just 6 buttons on the main screen) there's hope of getting Pleco into the hands of just about every Chinese language student with an iPhone.

 

[character]

[...]I wouldn't launch an Android port without assuming there were going to be at least a couple of things which the OS was supposed to do for us that we'd end up needing to reimplement on our own, and that makes the performance of low-level code a major concern.

What Android brings to the table that the others don't is that it's Dalvik JVM is able to run most existing Java jars, so you can take advantage of well-tested/known code libraries.

The interesting Pleco code is all written not in C++ but in plain old C [...]

I had gotten that impression.

I disagree with you about iPhone pricing, though - there's no way we could charge $200 for even a highly-specialized piece of iPhone software like Pleco.

It's certainly fine with me if it's cheaper. I just see people on chinese-forums making phone purchase decisions based on what will run Pleco, which makes me think you have some pricing power. Pleco brings an established market with it to the iPhone, and these days there is a real comparison to be made between Pleco and Wenlin. When one is working on a PC, there are tools such as ZDT and lots of websites to use; that's not really the case in the mobile space.

 

[mikelove]

That's a fair point on pricing power, but since Pleco's not being run solely as a profit-making enterprise (the nice thing about not taking VC money) there's also some appeal to making our software accessible to larger numbers of people if we can make that work business-wise. Of course that same accessibility argument would also apply to putting it on Android, I suppose

As far as the business end of it, however, the fact that a lot of people would no longer be buying a device specifically to run Pleco changes the math of price decreases considerably. That $300 figure I mentioned may be a bit on the high side, but let's say a new PDA costs $200 on average. Total price for that plus Pleco 2.0 Professional is therefore $300. If we lower our price by 25%, to $75, that has a big impact on us (especially since a lot of the royalties we pay are in fixed dollar amounts and don't go down when the price goes down), but from the customer's perspective the price has only dropped from $300 to $275, so we're not likely to sell very many more copies at the lower price.

Take away the PDA, however, and now it's just a question of the customer paying $100 versus $75, which could have a much bigger impact on sales. But it's not clear how big, which is the nice thing about releasing the iPhone version in stages (no flashcards in the first release, etc) - if we find we've set the price too low / high we've got a lot of opportunities to change that.