Google Android

[koreth]

I'd be way more interested in a tablet-optimized version of Pleco than a desktop-optimized one.

For me, though, having Pleco in my pocket with handwriting recognition is pretty much a requirement when I'm in China since I like to look up random characters on signs and such when I'm out and about. (Radical input would be acceptable, barely, but hunting through radical lists is much more laborious than scribbling an unfamiliar character.) Flashcard support is a must-have for me since I review flashcards on a daily basis, especially when I'm back home in the US and not immersed on a daily basis. I don't really care as much about the document reader or popup definitions or audio.

To the broader point, I think Pleco is probably making the right business decision to focus on the iPhone and iPad. If I were in mikelove's shoes I wouldn't be doing an Android port either, though it pains me a bit to say that as a customer who would be likely to buy it.

But since ideas are being floated here, I'll toss out one more that might or might not be practical: for flashcards, how about "supporting" them by communicating with a user-configurable external app? I bet there are enterprising Pleco-using techies who would either write their own flashcard modules or write bridges to talk to existing flashcard apps. For my usage, at least, if Pleco could pass in a dictionary entry (or even just headwords + pinyin) each time a flashcard was added from within the Pleco UI, I could easily be happy with a simple HTML5-and-Javascript flashcard interface and might write a simple one for myself. Crowdsourcing for the win. I don't know what the license implications of feeding dictionary entries to external apps are but it wouldn't be the end of the world if I had to enter my own definitions; I do that a fair bit anyway today.

 

[poncin]

I'd be way more interested in a tablet-optimized version of Pleco than a desktop-optimized one.

For me, though, having Pleco in my pocket with handwriting recognition is pretty much a requirement when I'm in China since I like to look up random characters on signs and such when I'm out and about. (Radical input would be acceptable, barely, but hunting through radical lists is much more laborious than scribbling an unfamiliar character.) Flashcard support is a must-have for me since I review flashcards on a daily basis, especially when I'm back home in the US and not immersed on a daily basis. I don't really care as much about the document reader or popup definitions or audio.

To the broader point, I think Pleco is probably making the right business decision to focus on the iPhone and iPad. If I were in mikelove's shoes I wouldn't be doing an Android port either, though it pains me a bit to say that as a customer who would be likely to buy it.

But since ideas are being floated here, I'll toss out one more that might or might not be practical: for flashcards, how about "supporting" them by communicating with a user-configurable external app? I bet there are enterprising Pleco-using techies who would either write their own flashcard modules or write bridges to talk to existing flashcard apps. For my usage, at least, if Pleco could pass in a dictionary entry (or even just headwords + pinyin) each time a flashcard was added from within the Pleco UI, I could easily be happy with a simple HTML5-and-Javascript flashcard interface and might write a simple one for myself. Crowdsourcing for the win. I don't know what the license implications of feeding dictionary entries to external apps are but it wouldn't be the end of the world if I had to enter my own definitions; I do that a fair bit anyway today.

Just to push that idea further, I would find it very convenient - without going as far as a "full blown" desktop version -, to have my phone connected via usb, to have pleco producing html output on the phone and me going through my flashcards on the PC in a browser pointing to the phone. No need to wonder about license implications of extracted dictionary entries, no need to redesign the engine, no need to synchronise statistics between PC and phone, ... just plug it and render from the phone (anyway, I need to recharge it). It might even be an additional $$$ feature.

 

[character]

[...] programmer mikelove hates Java and is sick of writing (or helping to write / supervising the writing of) the same code over and over again [...]

Can you carve out some time to just play with some interesting parts of the platform? The Native Development Kit, OpenGL ES, etc. Maybe along the way you'll find it's not so bad to program after all, or that you can keep most of the app in C and have someone else do the rest.

What really bothers you about Java? Object orientation? Performance? There are good books on performance tuning Java, FWIW.

[...] and Ivy-Leaguer mikelove just likes arguing the opposite of whatever everybody else is arguing

That would explain why you constantly disagree with my perfectly reasonable suggestions. :wink:

 

[mikelove]

numble - that's a good explanation, but I'm still not sure if that covers it; depends on how exactly Adobe's system was going to work, it's possible they might have implemented it in such a way that it would just as optimizable as something built in XCode. I suspect Apple will circle the wagons this weekend and sometime next week (maybe Monday so they get it out of the way before the Tuesday MacBook Pro announcement) Phil Schiller or some other VP will come out with a thoughtful-but-intentionally-vague statement that nonetheless makes it clear they're not blocking Unity or anything else that people use to make good iPhone software, just Flash, which even most of the people attacking this decision seem to dislike.

Zeldor - the problem with Android tablets is that there's nothing to put them in the hands of consumers; I doubt Android would have gotten any more of a foothold in the US than OpenMoko if every cell carrier other than AT&T hadn't been pushing Android phones aggressively for the last year. Or that it would have gotten a foothold in Europe if the European carriers weren't similarly pushing it now. The most successful Android tablet in the US will be whichever crappy rebranded Taiwanese thing buys its way onto the shelves of Best Buy, and its sales will amount to a rounding error compared to iPad's. (unless you count the Barnes & Noble Nook, but since all it can really ever do is read books, I don't) It's just like the situation with MP3 players - there were a zillion similar-looking bits of plastic crap, and then there was the iPod, and even after those zillion other players started to organize and set up music stores in ways that allowed people to move songs from one to another, the iPod still kicked their butts.

Windows, however, has the massive marketing resources of Microsoft and the still-struggling-for-relevance PC makers behind it, and if MS + HP put enough money into marketing their iPad competitor, there's a chance that that at least might establish an actual foothold, particularly if they push it specifically as a netbook alternative (with a whole ecosystem of docks / external storage / etc to go with it).

But yes, obviously I can't make any promises about this so early on, but at least assuming our Android software was sold (and still could viably be sold) through our own store instead of Android Market, we'd certainly plan to let people upgrade for free / for the difference in cost, and if it had fewer features we most likely would try to charge less for it (to the extent that that was possible given license fees).

koreth - an external interface for flashcards certainly might be a possibility, but I think at least initially we'd just use our simple little text list output feature - since that can even include definitions from a lot of dictionaries, it should be easy for another program to bring those in / check for and bring in newly-added words / etc. If our prospective Android software caught on, we could certainly investigate something more streamlined, assuming that we didn't decide to go ahead with a full-featured Android version ourselves.

poncin - we've played with a few iPhone-hosted-web-app-on-the-desktop ideas like that, actually; it wouldn't be possible over USB, but over local WiFi at least it wouldn't be that much work at all; just stick an HTML user interface on top of our flashcard back-end. Would also have some applications as a makeshift desktop-based flashcard organizer / editor / etc. Heck, we could probably even build a handwriting recognizer in there with HTML5 But I'm not quite sure yet how long that would take or where it should sit in our priority list - even as an experimental feature it might be a good way to try out some ideas for an eventual fully-web-based product, though.

character - I have played with them; the fact that my opinions about Java are so visceral-sounding doesn't mean they're completely uninformed. OpenGL ES we use on iPhone, that's not anything Android-specific, and NDK to me is almost eerily similar to the PNOlet system used on Palm OS for running bits of optimized code in ARM; same awkward data structure conversions and difficult debugging. Absent NDK, the cross-platform Pleco "core" (excluding flashcards / document reader / custom UI controls / custom font rendering system) is about 25,000 lines of densely-packed C that would have to be rewritten in Java, much of it not very easily since it uses a LOT of pointer arithmetic. That's not a ridiculously large programming workload, but it's not trivial, particularly not if we want to get it running at an acceptable speed, and once we've done it it's equally non-trivial to keep porting over new features to it. (assuming we even did)

 

[poncin]

poncin - we've played with a few iPhone-hosted-web-app-on-the-desktop ideas like that, actually; it wouldn't be possible over USB, but over local WiFi at least it wouldn't be that much work at all; just stick an HTML user interface on top of our flashcard back-end. Would also have some applications as a makeshift desktop-based flashcard organizer / editor / etc. Heck, we could probably even build a handwriting recognizer in there with HTML5 But I'm not quite sure yet how long that would take or where it should sit in our priority list - even as an experimental feature it might be a good way to try out some ideas for an eventual fully-web-based product, though.

On Wm6, USB is fine, you just need an adequate config and you can easily ping you phone. I know it because I'm currently using MyMobiler to review my flashcards . Refresh is a bit slow but working fine.

Ethernet adapter Local Area Connection 3:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Windows Mobile-based Device
Physical Address. . . . . . . . . : 80-00-60-0F-E8-00
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 169.254.2.2
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
DHCP Server . . . . . . . . . . . : 169.254.2.1
Lease Obtained. . . . . . . . . . : 10 April 2010 18:10:48
Lease Expires . . . . . . . . . . : 10 May 2010 18:10:48

 

[character]

Zeldor - the problem with Android tablets is that there's nothing to put them in the hands of consumers; [...] The most successful Android tablet in the US will be whichever crappy rebranded Taiwanese thing buys its way onto the shelves of Best Buy, and its sales will amount to a rounding error compared to iPad's.

Not just you, but everyone who talks down Android tablets fails to mention the upcoming Dell one, which is rumored to be headed to AT&T.

character - I have played with them; the fact that my opinions about Java are so visceral-sounding doesn't mean they're completely uninformed.

By play with Java I mean use it enough to learn to love it. :wink:

OpenGL ES we use on iPhone, that's not anything Android-specific [...]

But have you gotten C code rendering OpenGL ES on the Android simulator, perhaps with some touch input from the Java side?

[...] NDK to me is almost eerily similar to the PNOlet system used on Palm OS for running bits of optimized code in ARM; same awkward data structure conversions and difficult debugging.

Similarly, (and I appreciate this is non-trivial) have you written something in C which reads your existing C code and automates creation of the NDK C/Java interface layer? Perhaps start with a representative header file and figure out the conversions to automate. Then you wouldn't have to maintain/debug the conversion code, and when you change your C code you can just rebuild the conversion layer and fix up the Java side.

 

[mfcb]

On Wm6, USB is fine, you just need an adequate config and you can easily ping you phone. I know it because I'm currently using MyMobiler to review my flashcards . Refresh is a bit slow but working fine.

just a side note: FORGET MyMobiler, GO FOR EveryWAN Remote Support Personal Edition !
i used MyMobiler for quite some time, until i found this piece of excellent and free-for-personal-use software

 

[mikelove]

character - the Dell tablet is supposed to have a 5-inch screen, so the reason people don't mention it is that it's really more akin to a big iPod Touch than an iPad; a keyboard-less MID, basically. It lives in that awkward realm of devices too big to fit in a pocket but too small to comfortably display regular-computer-screen-optimized websites, and while it certainly might find a niche for some things (would make an excellent portable movie viewing system if it has sufficient battery life / storage capacity, e.g.) I don't think it's really an iPad competitor; it's not different enough capabilities-wise from a smartphone to justify the average consumer's owning one.

I haven't played with OpenGL on Android much because it's honestly not a big deal; I've been pretty much assuming that part would be easy. There are only a few dozen lines of OpenGL code in Pleco on iPhone, we only use it for handwriting recognizer stroke rendering; we may adopt it for stroke order diagrams soon too, but that would only be a few dozen more lines since the rendering / animation / etc is already vector-based (just in Quartz instead of OpenGL). So presumably since the underlying commands are the same we'd just replace the C calls with their Java equivalents.

Even assuming we had a magical Perl script that could do all of the work of wrapping up our C functions in Java with perfectly reliable variable / type conversions, and seamlessly update them every time we changed them in C, that still wouldn't take care of the debugging issue. On Palm, bugs that would take half an hour to fix in 68k code took 2 days to fix in native; in both cases we were working with well-tested code, in fact on Palm a lot of those bugs were in the extremely-thoroughly-tested-but-not-in-Palm-OS-PNOlets SQLite library, but there are always platform-specific quirks to deal with.

So the only option that lets us emerge from this exercise with some shred of sanity left is to rewrite the engine in Java, and offer our humble apologies to Android users upset about the fact that, on account of the two different code bases we then have to maintain, iPhone users are getting new features 6 months before they do. (or getting some particularly new-code- or performance-intensive ones exclusively on iPhone)

 

[character]

character - the Dell tablet is supposed to have a 5-inch screen, so the reason people don't mention it is that it's really more akin to a big iPod Touch than an iPad; a keyboard-less MID, basically.

True -- in some ways my comment was a knee-jerk response to the old "there is no Android Touch" statement. OTOH Dell has built out its computer line by releasing models with different screen sizes, so the tablet may be the same, esp. if the iPad takes off.

It lives in that awkward realm of devices too big to fit in a pocket [...]

Because the Dell tablet is so thin, it does fit into a front pants pocket.
http://www.engadget.com/2010/02/19/dell ... pressions/ "Understandably, most people are concerned about whether this 5-inch tablet would fit inside their pocket. We're happy to tell you that it snuggled nicely in our jeans' pockets, which is most likely to do with the device's sensible thickness and our lack of tight pants. Apart from the slight exposure (as pictured below) and the occasional struggle when walking up stairs, we've had no other issues with pocketing our Mini 5."

I haven't played with OpenGL on Android much because it's honestly not a big deal [...]

At one point you wrote about the possibility of doing an OpenGL UI.

Even assuming we had a magical Perl script that could do all of the work of wrapping up our C functions in Java with perfectly reliable variable / type conversions, and seamlessly update them every time we changed them in C [...]

My experience writing code and fixing other people's code is that people tend to solve problems the same way over and over, so I suspect the conversion code would have to handle a relatively small number of cases. The bonus would be if you got something which worked to your satisfaction, you might be able to sell it as an (admittedly low-volume) product for developers.

[...] that still wouldn't take care of the debugging issue.

I assume/hope you've got some automated tests for your code. You could verify that what you put in on the C side comes out correctly on the Java side, so you can have some confidence the problem lies elsewhere (possibly by plugging the values from any problem cases into your tests and seeing the values are correctly converted).

http://cunit.sourceforge.net/
http://www.junit.org/

So the only option that lets us emerge from this exercise with some shred of sanity left is to rewrite the engine in Java, and offer our humble apologies to Android users upset about the fact that, on account of the two different code bases we then have to maintain, iPhone users are getting new features 6 months before they do. (or getting some particularly new-code- or performance-intensive ones exclusively on iPhone)

Actually Mike, it looks like Steve Jobs is going to continue to alienate iPhone developers (probably a big hike in the $99 fee is next) and customers (buy a V2 iPad to multitask), Android is going to fragment to oblivion, Web OS is a Dead Phone Walking, and traditional PCs are being replaced by tablets and cloud-based apps. The only sane solution is to write a Windows 7 Phone app. :wink: I'd say an HTML5 local storage version of Pleco might make more sense, but no one should have to write complex applications in JavaScript.

 

[mikelove]

Yes, but optimizing software for a 5-inch screen is very different than optimizing it for a 10-inch screen; absent a big, popular Android tablet there's not going to be much financial incentive for Android developers to develop iPad-scale tablet-optimized apps. Say what you will about Apple, they definitely know how to create a buzz; since there's no way Android matches that, they need to get a bunch of big companies pushing Android tablets instead of iPads. But unlike with cell phones, where in most markets there were at least one or two big carriers left out of the iPhone bonanza and consequently very eager to push any alternative they could get their hands on, there's really nobody in the Android market in a position to push 10-inch devices onto the market as aggressively as Apple has done. So you end up with PC makers selling $400 tablets at Best Buy as thinner-but-still-Windows-powered netbooks, and Apple owning the rest of the market with their uncontested tablet-specific ecosystem.

An OpenGL UI is something we've concluded is unrealistic - sorry I forgot to mention that; it's just too darn awkward, and there are too many things even a comparatively-wussy OS like old-school Palm did for us that we'd have to duplicate ourselves in an OpenGL-based UI.

Pleco's C sources aren't as clean as one might hope, sadly; there's some really nasty stuff in there that was necessitated by our support for Palm OS (we still use memory handles, for cryin' out loud), but it's nasty stuff that's been very well debugged, that still works perfectly on modern systems (not exactly hard to emulate handles on systems that don't use them), and that would take almost as long to modernize as it would to rewrite altogether. And automated testing can find bugs, but it can't fix them for you.

So there's a great deal of reason to think a Java rewrite, however unpleasant, would be a better idea than a duct-tape-and-chewing-gum NDK version. Plus, a Java port has the added advantage of potentially working on BlackBerry; if we're buying into the possibility of a watered-down "Pleco Lite" still being a successful product in mobile software markets that are poorly-served by other Chinese dictionary makers, we might as well offer it to the large and persistent BlackBerry contingent along with the Android one. (many of whom have shiny gold AmExes and won't think twice about putting a $200 Chinese dictionary on their corporate card)

Oh, and Apple just cut the fees for the OS X developer program to $99 on account of the iPhone program being so successful, so I don't imagine they're like to raise them anytime soon.

 

[Zeldor]

mike:

Sure, no one is saying there will be other single device beating iPad, even it if will be much better and cheaper. Many people are just stupid [sorry for my words] and buy crap. But they need nothing more. The truth is that you are not going to sell Pleco to them. There is really big group of people that want something more. And it's a bit different group of people - more conscious and more demanding than standard Apple fanboy/girl. I can bet that they are going to spend much more money on average on software like Pleco. It's really not if you should make your software for something else than iPhone/Pad, the real question is what should be the 2nd platform. Sure, you will get less money from that. But you can probably get for example more free advertisement out of those people. iPhone/Pad is not a business/learning tool and won't be any time soon. And there really should be a tool to learn/use Chinese language for people that don't intend to buy an overpriced game console/web browser. And I don't think there is any other platform better than Android now. Both Palm and Windows commited suicide, there is no coming back from that.

 

[numble]

You are funny, Zeldor. There are already people on this forum using Pleco on the iPad, but I doubt any are using an Android tablet, so your argument that "stupid" iPad users will not buy Pleco is curious. I think the fragmentation problem amongst Android tablets is potentially even worse than on the phone side, with different screen resolutions, styluses, processors, RAM, trackpads, physical buttons, etc. Maybe Google will step in and impose some order, but I thought that was what they wanted to do with Chrome OS.

I think cell phone carriers will need to offer subsidized versions of Android tablets for it to see any type of wide adoption--I'm not even sure if there is that much interest in 3G tablets--Apple sold half a million of the 3G-less iPads in a week, and I don't think the 3G versions will be more popular. Otherwise, Android tablets will be struggling to get into Best Buy and WalMart, and at least Apple offers the proposition that if something goes wrong within a year, you can get it replaced the same day by going to a nearby store, as opposed to dealing with a startup company in India run by a handful of recent grad students. For today, Apple says to developers that you have 500,000 potential customers a week after launch. What is the Android tablet proposition?

I posted this from my iPad, by the way.

 

[Zeldor]

numble:

You know well that I was just talking about average iPad user Maybe 'stupid' is not the best word, that I can agree on. All I wanted to say that you shouldn't look at how many iPads get sold - most of people that get them, won't be interested in any serious software like Pleco. And you'd get much higher % of people interested in let's say Android users group.

Sure, Android tablets are few months away [July-August probably] and they will be subsidized. But I can be just guessing how it will look exactly BTW, spending additional hmm... $250? for 3G on iPad seemed probably too much for most of the people.

 

[character]

Archos promises six Internet Tablets this summer for hands of all sizes From the machine translation of the source article, it sounds like they will all be Android-based.

Mike, I look forward to reading which path you decide to take WRT Android/desktop, Java/C, etc. But you change your position so much I don't feel I can help at all by discussing it with you, so I'm going to try to stop making suggestions. No hard feelings, etc.

 

[Zeldor]

character:

Google Tablet also going to appear. http://www.slashgear.com/google-tab...ereader-tipped-to-take-on-apple-ipad-1281228/
And Meizu Android tablet: http://www.slashgear.com/meizu-mbook-1080p-capable-ipad-rival-detailed-1281195/

 

[numble]

numble:

You know well that I was just talking about average iPad user Maybe 'stupid' is not the best word, that I can agree on. All I wanted to say that you shouldn't look at how many iPads get sold - most of people that get them, won't be interested in any serious software like Pleco. And you'd get much higher % of people interested in let's say Android users group.

Sure, Android tablets are few months away [July-August probably] and they will be subsidized. But I can be just guessing how it will look exactly BTW, spending additional hmm... $250? for 3G on iPad seemed probably too much for most of the people.

Where do you get the data point that a higher percentage of people interested in Android are interested in purchasing Pleco? I can see it possibly being profitable on the phone side, but even there Mike seems to project that the sales will pale in comparison to iPhone sales. Of course most users of both platforms will not have much interest in licensed dictionary software. The extra cost for the 3G is $129, by the way.

Considering that Apple introduced the iPhone at $599 and now is offering it for $99 subsidized, it's possible that they will compete on price once suitable competitors appear, following what they did with the iPhone. I still believe that the fragmentation is going to be more intense with the Android tablet market, and it would be silly for anyone to start to develop a tablet Android software right now, when the screen sizes, RAM availability, processors, etc. are still not finalized, let alone the market.

 

[westmeadboy]

Where do you get the data point that a higher percentage of people interested in Android are interested in purchasing Pleco?

http://www.readwriteweb.com/archives/wh ... s_male.php

If (and this is a big "if"), the majority of existing Pleco users are male, then the above link would support Zeldor's claims.

@numble: BTW, you've mentioned a few times about screen sizes, RAM, processors (things that vary on smartphones as well as tablets) etc but none of these have caused any problems for any of my apps. I remember (at the start of this thread) someone mentioning that some devices having /not having a hardware keyboard as being a potential problem but that was yet another "problem" that never was.

Also, with all this talk of lack of hardware configuration consistency, I wonder why when the iPad was announced there was not more "Oh no! another screen size to support". Instead, the reaction was more "great, look at what we can do with this", which is, of course, much healthier.

When I started this thread 18 months ago it was intended to be a discussion about how great Pleco would be on an Android device. So we talked a lot about things like custom IMEs and other things which can only really be achieved on Android.

Unfortunately, a lot of these 22 pages have turned into an iPhone vs Android debate (and I'm as guilty of that as anyone, I guess!). Indeed, there have been some posts which don't talk about Android at all.

If someone was to only read Mike's posts on this thread, they would naturally come to the conclusion that Android was a POS and probably resembled something like MS DOS

Anyway, I hope we can get some more positive posts

In what way could Pleco shine on the Android platform? Discuss.

 

[numble]

Where do you get the data point that a higher percentage of people interested in Android are interested in purchasing Pleco?

http://www.readwriteweb.com/archives/wh ... s_male.php

If (and this is a big "if"), the majority of existing Pleco users are male, then the above link would support Zeldor's claims.

@numble: BTW, you've mentioned a few times about screen sizes, RAM, processors (things that vary on smartphones as well as tablets) etc but none of these have caused any problems for any of my apps. I remember (at the start of this thread) someone mentioning that some devices having /not having a hardware keyboard as being a potential problem but that was yet another "problem" that never was.

Also, with all this talk of lack of hardware configuration consistency, I wonder why when the iPad was announced there was not more "Oh no! another screen size to support". Instead, the reaction was more "great, look at what we can do with this", which is, of course, much healthier.

"If the majority of games are for males, then the above link would support the claim that most mobile games will come out on Android devices, or a higher proportion of Android users will buy games."

But that's not actually a good logical proposition. But anyway, arguing for getting a higher proportion of a particular platform is nonsensical. Pleco could release a JooJoo port and capture 80% of the Linux tablet market, but that will maybe only be a handful of people.

The iPad being a different hardware configuration still causes issues--look at how many people are complaining about how their favorite iPhone App is not iPad ready at launch, and they are not happy with just simply rescaling the iPhone screen. But at least all of the 500,000+ iPads in the wild require the developers to port to one version of screen size and RAM only, as long as an App isn't greater than 16GB. The complaints would definitely be greater if there were multiple iPad screens, processors, and RAM configurations for the developers to adopt to.

 

[westmeadboy]

"If the majority of games are for males, then the above link would support the claim that most mobile games will come out on Android devices."

No that's different, the above link would not support that. It would support that if a game was released on Android, then a higher proportion of Android users would be interested in it.

The iPad being a different hardware configuration still causes issues--look at how many people are complaining about how their favorite iPhone App is not iPad ready at launch, and they are not happy with just simply rescaling the iPhone screen. But at least all of the 500,000+ iPads in the wild require the developers to port to one version of screen size and RAM only, as long as an App isn't greater than 16GB. The complaints would definitely be greater if there were multiple iPad screens, processors, and RAM configurations for the developers to adopt to.

This is because iPhone devs designed their apps to run on one screen size.

Guess what would happen if Google released a gPad tomorrow. Same problem, right? Wrong.

Nearly all the Android apps would work instantly. No, the screens wouldn't be simply scaled up because Android devs know how to use screen layouts properly. Not because they are cleverer, but because they had to.

This is the problem with constantly going back to this iPhone vs Android debate. People assume that a problem on one device will become a problem on the other, arriving at such conclusions using crude extrapolations. But these two platforms have evolved in very different ways.

 

[numble]

"If the majority of games are for males, then the above link would support the claim that most mobile games will come out on Android devices."

No that's different, the above link would not support that. It would support that if a game was released on Android, then a higher proportion of Android users would be interested in it.

The link shows that a lower proportion of Android users pay for Apps as well, so unless we have data about Chinese language learners and technology, the link clearly disputes Zeldor's main arguments:

[iPhone OS users] need nothing more. The truth is that you are not going to sell Pleco to them. ... I can bet that [Android users] are going to spend much more money on average on software like Pleco.

The iPad being a different hardware configuration still causes issues--look at how many people are complaining about how their favorite iPhone App is not iPad ready at launch, and they are not happy with just simply rescaling the iPhone screen. But at least all of the 500,000+ iPads in the wild require the developers to port to one version of screen size and RAM only, as long as an App isn't greater than 16GB. The complaints would definitely be greater if there were multiple iPad screens, processors, and RAM configurations for the developers to adopt to.

This is because iPhone devs designed their apps to run on one screen size.

Guess what would happen if Google released a gPad tomorrow. Same problem, right? Wrong.

Nearly all the Android apps would work instantly. No, the screens wouldn't be simply scaled up because Android devs know how to use screen layouts properly. Not because they are cleverer, but because they had to.

This is the problem with constantly going back to this iPhone vs Android debate. People assume that a problem on one device will become a problem on the other, arriving at such conclusions using crude extrapolations. But these two platforms have evolved in very different ways.

The complaints are mostly about providing additional functionality with the extra space and taking advantage of the extra processor speed and graphics processing, and in some cases, storage. Compare the NYTimes, NPR, IM+ or other iPad-optimized apps with their iPhone versions, and you'll see that it's not simply adopting readjusted layouts. If you think Android tablet users won't be complaining to devs about not releasing tablet-optimized software of their phone software on day one, that is just silly.