Slashdot Mirror

I responded with "And yet the UI pales compared to a closed-source project like iOS, and it's still a single company driving development, unlike your average OSS project, so it's not even that good an example."

Do you get it now? Do I need to use smaller words?

Why use small words when I can sum up my thoughts in 2 letters? Here they are:
bs

This is just pure FUD.

No it's not. I invoked no fear, created no uncertainty, nor implied any doubt.

Yawn. You said Android isn't an open source project. It is. Look up the word uncertainty.

Aside from the kernel (which has fuck-all to do with the UI), does android have a large community of volunteer developers?

Unbelievable. Yeah, aside from that kernel that has been continuously developed and refined for almost 2 decades and has had billions of dollars pumped into it, Android is just pure Google. I'm sure it took much more effort to come up with the DalvikVM and bionic than that one little kernel. It's just out of the kindness of their hearts that they decided to go with Linux rather than just whip up their own in their spare time.

No. It's no different than, say, Java: virtually all development is done by a single, commercial organization, that then releases their work for free.

See my previous statement.

Now, please, Android-fanboy, leave me alone.

Wow. Name calling. Your arguments just get better and better.

Companies including RIM, Nokia, Microsoft and Apple should watch out for Android with its Linux roots. Development appears to be fast. At this speed their lunch is at risk.

What appears to be holding Adroid is "bad" publicity on battery life, the poor organization of the Android Market including poor quality apps and the [subjective] poor user experience on high end phones.

As a matter of fact, the state of the Android Market is severely anaemic because whereas apps in this market are said to number about 75,000 now, having a look over here does not show any figure near that!

To make matters worse, there is no provision for searching for an app whose name you might not remember well. What surprises me is that the market is owned by a company (Google) which boasts of the greatest and best search engine in planet earth! Think about that for a moment.

Now before I get flamed, I know there is AndroLib. What I am talking about are efforts by the search giant Google.

That isn't resolution independence. A resolution independent UI adapts to new screen sizes not by scaling coordinates, but by actually changing the layout of components.

You don't know what you are taking about. That's just screen size independence. Something for example Windows has had since v2.0 back in to 1980s. Resolution independance is a whole lot more, and Windows again for example, only started getting resolution independance in Windows Vista.

Read and learn:
http://en.wikipedia.org/wiki/Resolution_independence
http://developer.android.com/guide/practices/screens_support.html

Resolution independence includes all the things I mentioned and more. And if you look at the Android page - be sure to read it all - you'll see it deals with most of them.

Don't bother trying to argue the toss with me. I've been developing smartphone UIs for more than a decade.

You can see exactly how iOS handles larger screens by looking at iPhone apps on iPad: you get a big black border, a pixelated keyboard, and a layout that is ill-suited to the large screen.

Here's a screenshot of Aldiko as displayed on an Android tablet. It's had a good try at resizing for the larger screen BUT The font has gone wrong, and so you can't read any of the labels.
http://www.droidsector.com/blog/wp-content/uploads/2010/04/aldiko-shelf.jpg
Many other Android phone apps simply won't install at all on an Android tablet.

You see whilst an OS can supply the facilities for resolution independence, it needs app developers to use them. Apple took the approach with the iPad that would allow EVERY iPhone app to run, no matter whether the developer had taken care to be resolution independent or not.

Meanwhile iPhone OS 3 and earlier apps run on the iPhone 4 in full resolution for any text or anything that's drawn, or anything that uses system controls. The only time there will be pixel doubling is for bitmap app resources.

Again, if Apple had chosen to release an iPhone with a different pixel density, it would also have worked. But none the legacy apps wouldn't have looked as nice.

There's a difference between what the app supports, what app developers do, and what looks good, that I think is too subtle for you.

It exposes a limitation of the operating system, and it forces a bad design compromise. Putting a 323dpi screen on a cell phone is a bad cost/benefit tradeoff.

The limitation is only your ignorance of how iOS works. And a superior higher res screen for a price the same as last years model and lower than the HTC EVO 4G is hardly a bad tradeoff. If Android had a screen with an equal or higher res screen, you'd be praising it.

You can't compare phone prices that way because phone companies play games with subscription rates. The iPhone costs more than $1000 when purchased separately (outside the US), compared to about $500 for the Motorola Droid (in the same markets).

I'm in the UK. The iPhone 4 starts at £499 which is $754. So again you're either mistaken or just making things up. The Motorola Droid is last years model - and I can't find a UK unlocked price for it.

Oh, so you're just stupid. Android is built on Linux. Pretty much all of it is open source:

http://source.android.com/

Yet you still have not mentioned who that gatekeeper is,

Wow, you just don't get it do you? The gatekeeper is not a who, but an it - it is the operating system's own security model that enforces it,

... Standing next to an open gate waving to people as they walk by is hardly acting as a gatekeeper.

Link pls.

So, you're arguing the policy with me without even having the ability to find it?

No, I'm done.

Yet you still have not mentioned who that gatekeeper is,

Wow, you just don't get it do you? The gatekeeper is not a who, but an it - it is the operating system's own security model that enforces it,

I already did. Google's published privacy policy. Check it out

Link pls.

Setup your environment

And to my first impression (you never know for sure until you try), create an app which hooks to BroadcastReceiver and poke around with it.

Maybe even grantUriPermission on a service.

Setup your environment

And to my first impression (you never know for sure until you try), create an app which hooks to BroadcastReceiver and poke around with it.

Maybe even grantUriPermission on a service.

Setup your environment

And to my first impression (you never know for sure until you try), create an app which hooks to BroadcastReceiver and poke around with it.

Maybe even grantUriPermission on a service.

So could Google - but no one seems to be bitching about Google Code.

Google has been a great friend of open source. They have earned and continue to earn a great deal of trust and respect from the open source and free software community.

Compare to the current CEO of Microsoft and I think it will be clearer why Microsoft needs to do more.

For anyone who thinks the parent is joking:

android.Manifest.permission.BRICK - Required to be able to disable the device (very dangerous!).

I've always wondered exactly what classes and methods that permission enables...

(posting AC because the parent was worth modding Funny to other Android devs)

That's why it only sells on the closed networks in the US.

Which closed network? T-Mobile? AT&T? Verizon? Sprint? MetroPCS? Is there even a single actual network that doesn't sell Android phones anymore? Go ahead. I dare you. Name a single one. Or did you mean Android only sold on all the networks of the US (therefore implying that all the networks in the US are closed)? Because, I can tell you. I'm currently in the UK right now, and there isn't a single shop in the UK that doesn't have Android devices on sale right now and that aren't selling like hot cakes. And sure, the iPhone is still very popular in the UK right now, but at the sales counter where it counts, it's getting assaulted by several very good Android phones that are all selling just as well as the iPhone. It's not fair fight anymore. One phone against 39 phones, several of which are actually far superior to the new iPhone.

That's why 75% of Android devices run v1.6.

No, it's more like 50% of the Android devices are running v2.1. I can cite my source. Can you even cite yours?

Being able to port desktop C apps over rather than rewrite in Java only becomes even more important.

Please repeat after me: The C and C++ apps of the Android NDK do not run on the Dalvik VM. The C and C++ apps of the Android NDK do not run on the Dalvik VM. Please repeat this one hundred times.

and the next thing you know "Android will be better next year!"

If anyone is saying that, and repeating it ad nausea um, you're the only one. I've corrected your strawman argument plus several of your other factual errors in your other threads. But you don't even seem to even read my responses, or even care about citing your sources.

The native API is closed. You have to rewrite in Java,

This is false. See here.

which is why Ansroid is missing so many categories of software and why the overwhelming majority of Apple developers are Apple-only.

Also false. iPhone has more applications because it has been out longer and there are more people with iPhones who buy apps thus providing the incentive and momentum for more applications to get written. As Android continues to mature and grow, this may change.

If they're such pieces of shit, where are the open standard wondrous operating systems?

Perhaps here? Or maybe even here?

Only Google can make native C Android apps. No 3rd parties have access.

What rock did you crawl from under? Android NDK has been available for ages.

Same with Chrome OS.

There's no device shipping with OSS. Then, of course, since it's fully Open Source, you're free to compile native apps for it and add it to the distro as you see fit. And one of those apps could be a package manager.

what is worse, there are so many diverse entries that I don't think there ever will be a viable competing ecosystem.

With Google and hardware manufacturers working together to avoid fragmentation, I think android with be able to compete. Not only that you'll have stuff like this, this, this...etc. you will also have the rest of the marketplace in which Google encourages people to develop the way they want to.

The oldest Android phone runs android 1.5 and even in 1.5 absolute pixel values were deprecated...

http://d.android.com/guide/practices/screens_support.html

Are the screen sizes a big deal? Application and web developers have dealt with this problem for decades now.

No they aren't. Android 1.6+ has a very robust way of dealing with virtually any screen size.

http://developer.android.com/guide/practices/screens_support.html

I've developed 7 Android apps and the huge diversity of Android versions and devices out there really is a nightmare. I have an enormous number of extra code paths due to it. All this extra complexity makes apps tougher to write, tougher to test, tougher to debug, tougher to enhance.

Some examples of bizarre stuff I have to do:
Android 1.5 has a Java NIO bug that forces me to copy data to a temporary array on its way to buffers to be rendered via OpenGL. This hurts performance on older phones that often need it the most. It also means I have to do more testing to make sure both code paths are well exercised. I bet many developers don't even realize the bug is there an just have broken OpenGL apps on Android 1.5. The bug fix would be trivial to port back to Android 1.5, which would make it drastically more likely to get on to these older phones, but there's no sign this will ever happen. Do I keep code paths like this? Or do I give up the 25% of the market that is Android 1.5? Neither is desirable.

Another really frustrating one is how I have to detect specific devices and request certain size depth buffers just to get decent performance. Hardware graphics acceleration is only enabled on the Samsung Galaxy for depth buffer size 16, for example, not for no depth buffer. Depth buffer size 24 works best on the Droid, etc.. The Galaxy has had this bug for a very long time. The Archos tablet has no hardware acceleration and there are promises that cheaper phones will be similar. Do I write all the extra code for adjusting rendering for each of these? Or do again give up large swaths of the market?

Anyway, I'm constantly dealing with issues like this. It is really disappointing that Android team, the carriers, and the device manufacturers don't do more to prevent it. Doing things like back porting fixes so that older phones can be more trivially updated would help enormous numbers of apps and app developers compared to the very few resources needed on Google's part to do it.

Meanwhile Google isn't even interested in solutions to these problems from what I've seen. One developer brought up another potential solution during a session at Google IO. He suggested making the highest level of Android a distributable framework, like .NET. This would allow updating it much easier. Not nearly as many phones would be stranded with old, buggy versions of the Java portion of Android at least. The Google staffers just brushed the idea off without even discussing it. They said fragmentation should really be called progress and to deal with it.

This isn't really surprising. If you look at a recent app produced by Google, the Twitter app, you'll see that it is unavailable to a huge percentage of the market because they don't support older versions of Android with it. Independent developers can't afford to ignore large sections of the marketplace like that. Google isn't in the app business, so the Googlers just go ahead and ignore the issue. You can see a graph of the versions of the devices on Android Market here:
http://developer.android.com/intl/fr/resources/dashboard/platform-versions.html

And of course there are plenty of devices not on Google's market, many of which are even less likely to receive updates because they are updated by PC software rather than over the air.

So Googlers aren't even eating their own dog food on this issue. They just make app developers put up with it on their own, never experience it themselves, and then ridicule the issue as a bogeyman. I think I was happier before I read the blog post. At least then I could imagine they were working hard on the issue and just doing terrible at it. Now I know they don't even consider it an issue.

No, the C API on Chrome OS and Android is closed. It's Google only.

No it isn't.

HTML5 and Flash and Java applets only on Android.

You can run Debian on Android. It works fine. You can run GCC and compile whatever you want.

they just now figured out that memset() is supposed to be able to write values other than zero.

Looks more like a coding error than a lack of understanding...hence the fact that the function definition specified the data all along.

What is the NDK? It's been available for some time now. To the best of my knowledge writing a Dalvik shell to expose the app to the O/S and then using a native NDK core *is* the way to do what you are saying.

These guys ported Quake 3. It uses a lightweight Dalvik launcher to control a native build of Quake 3.

While there might be some utility to a way to write a pure native code user-facing app in C, I don't think it currently exists. Android's browser, for example, is a Dalvik wrapper around the native code. You can of course build a pure native code executable that will run on the terminal (for example, see here) but that's not going to be useful for you.

What Google should be doing is improving the speed and stability of the entire Android OS, most critically the Dalvik virtual machine. For crying out loud they just enabled JIT on 2.2.

I wouldn't hold my breath. It's 2010, and they just now figured out that memset() is supposed to be able to write values other than zero.

Users from other countries, such as Brazil in my case, won't even be able to play the official Tetris, since Google Checkout doesn't exist in Brazil; you can't buy paid applications from Android Market in these countries."

Also Brazil isn't listed in the list of supported locations for free publishers, I wonder how you were able to publish your app in the first place (and pay the $25 Android Market fee if Google Checkout doesn't work). I'm asking this because I'm from Brazil as well and I'd like to register as a free app publisher, but apparently Google wouldn't allow me to.

Android Market > Top Free > Brain & Puzzle > FallingBlocks, click it, and MobPlug is listed as the developer. Or do apps show up on the PC view of the site even if they have been deleted from the version on the handset?

And it's still there.
Look under "Top Free" and then "Brain and Puzzle" catagory.
I don't know if Google already restored it or it never came down but it's definitely available.

More of the excitement now is in mobile computing, which is highly proprietary.

The largest and the fastest growing mobile OS's are both open source. Where've you been?

Let me start some speculation here.

Apple took a bold move when they dumped their outdated and technologically inferior Mac OS and rather than starting from scratch they used open source (FreeBSD) at the heart of their new OS.

Another bold move when the Apple browser Safari was again based on an open source core (KHTML).

So I predict this new iPhone version will make the same bold and logical move and be based on ..... Android 2.2!

Go Apple! :) /me ducks for cover

I can't see how hobbyists would care for 100% coverage across all devices. Additionally, the UI toolkit for android is basically the same for all versions of the phone. Plus, you can write as many resolution implementations as you like more or less simply by the editor. Hell, why bother spewing useless anecdotes. Just go and get the SDK. It is FREE. Give it a try for 5 days and determine for yourself if its worth beans for YOU.

Eclipse IDE:
http://www.eclipse.org/downloads/

Android SDK:
http://developer.android.com/sdk/index.html

Android / Eclipse Integration:
http://developer.android.com/sdk/eclipse-adt.html

I can't see how hobbyists would care for 100% coverage across all devices. Additionally, the UI toolkit for android is basically the same for all versions of the phone. Plus, you can write as many resolution implementations as you like more or less simply by the editor. Hell, why bother spewing useless anecdotes. Just go and get the SDK. It is FREE. Give it a try for 5 days and determine for yourself if its worth beans for YOU.

Eclipse IDE:
http://www.eclipse.org/downloads/

Android SDK:
http://developer.android.com/sdk/index.html

Android / Eclipse Integration:
http://developer.android.com/sdk/eclipse-adt.html

This is so true. It would be "fragmentation" if those different versions were all incompatible with each other. But they aren't. Each version of the OS maintains complete backward compatibility with all previous versions. If you want to make your app run on all versions, just write it for 1.5, and it will work perfectly on all later versions as well. If you really need a feature introduced in a later version, target that one and you'll know exactly what fraction of the potential market you're excluding. Either way, you never need to write multiple versions of the app for different OS versions. That is not what I call fragmentation.

If you want to know what fragmentation is, look at Linux. I have to distribute separate 32 bit and 64 bit versions of my software, then discover it mysteriously segfaults when run under Ubuntu due to some subtle incompatibility between that and Fedora, which is what I compiled under. Very frustrating. If Linux managed its diversity half as well as Android does, that would be revolutionary progress.

Unless the app has been designed for this functionality in the manifest, it won't be able to be moved to the SD card.

http://developer.android.com/guide/appendix/install-location.html has more details.

According to http://developer.android.com/guide/appendix/install-location.html

* The .apk file is saved on the external storage, but all private user data, databases, optimized .dex files, and extracted native code are saved on the internal device memory.

* The unique container in which your application is stored is encrypted with a randomly generated key that can be decrypted only by the device that originally installed it. Thus, an application installed on an SD card works for only one device.

* Only new releases of apps can do this - they need to add "android:installLocation=preferExternal" to their manifest.

Have we audited the Android code enough to know that it's not phoning the mothership sending god-knows-what?

I'd say so. I pretty much know what my Android phone is sending back by casual observation, my contacts are synced with Gmail, it asks if I want to participate in X program (no) or send my location to google (no).

But hey, if you don't believe me do an audit yourself. The thing about secret plots is that the more people you involve in them the harder they are to keep secret.

Android's Market tells you exactly what an app can and can't access before you install it. In order to access certain classes of API, the app has to include this access in its manifest file or the API's aren't available. Examples include location (there are two tiers: rough network-based, and precise GPS based), phone (again, two tiers: phone state [usually to do things like pause music when the phone rings], and the ability to place/receive calls), network access, storage (read or modify SD card contents), SMS, camera access, contact data, calendar, email, phone sleep functions, and so forth.

Those access levels are detailed here:
http://developer.android.com/reference/android/Manifest.permission.html

Certain accesses are considered sensitive, and will be specifically brought to the user's attention before they install the app. Other controls (such as access to the phone's vibrate function) aren't, and although you can look to see if the app uses those functions, you're not bothered to verify that this is ok first.

So if an app wanted to poach your phone number, etc. on Android, it would basically have to advertise to you that it's doing so or it wouldn't have that level of access.

That said, I do wish there was a way to *block* those accesses.

Android probably never will go down that route, and as a result, no matter how successful Android phones become in the market, Android apps will never be as successful as iPhone apps.

not true, Android Marketplace?

The only problem is convincing developers there's a market there, or that developing for generic devices with any number of different features is a good idea.

Yeah, there definitely aren't any iPhone apps that have made it to other app stores (or vice versa). Nope, nope nope.

Apple supports both C and C++. If you design your app properly the porting isn't so bad in either direction. Yes, it's a bit harder than making your crappy Flash animation play on whatever. So sad.

1) Profit on selling the device itself (either unlocked to consumer or to AT&T)

Making a profit on a sale -- of a tangible good no less -- is now fleecing?

2) A nice MONTHLY cut of around $18 from AT&T from the subscribers min. of $70/month. (This is the real reason iPhone is exclusive to AT&T inspite of shitty service all around, notice how this isn't mentioned much here on /.?).

Unverified and irrelevant. The service charges are not higher for the iPhone versus any other phone with the same plan. You also get visual voicemail AT&T might be a ripoff, but that's on AT&T.

3) A FORCED 30% cut of all third party software sales for the iPhone/iPod Touch/iPad.

You say tomato, I say 70% royalties while maintaining ownership of published material. That's a far cry from what the old school publishing/distribution channels would provide, where royalties are exclusively for established authors and certainly never approach 70% of gross sales. And let's not forget that the Android Market takes exactly the same cut.

One thing Apple has, and nobody else does, is the ITMS (one stop shopping).

And android has the Android Market. The only difference is that you're not forced to sell your app through google if you don't wish to.

What can I say? You read wrong. Google is not sharing with carriers and handset partners. They do, indeed make money off of the Android market by sharing with developers:

Transaction Fees
For applications that you choose to sell in Android Market, the transaction fee is equivalent to 30% of the application price. For example, if you sell your application at a price of $10.00, the fee will be $3.00, and you will receive $7.00 in payment.[1]

...while in white-box hacking, users have access to the source code and can use automated or manual analysis to identify bugs.

Those closed source bastards!

...Please RTFLA before stating how "open" it is compared to the iPhone SDK: http://www.android.com/market/terms/developer-content-policy.html With that said there are two problems I have with the FSF commentary: 1. I know people love to use the car metaphor but I feel it's an apples and oranges comparison because the average can open up their car hood check and refill the oil without causing the engine to stop running, whereas the average user of a computer cannot be expected (or trusted) to do the same. Apple allows people to use the Terminal for command line troubleshooting which frankly is more powerful than the average user should have. I love how the FSF always implies a certain level of arrogance by Apple in locking down certain portions of the operating system but personally I think it implies more arrogance the FSF's part by assuming that people are willing to take a bunch of time to learn (or for that matter care) about the difference between the GPL and proprietary software licensing. I appreciate Free and/or Open Source as the ideal software development method, but I'm realistic enough to realize that unless the GUI and for that matter, the overall user experience for Linux and other GPL projects improve to where the average user can use it Linux is going to remain a tech enthusiast and corporate server level OS. If and when that day comes I will happily switch but for the moment I find the user experience on my Mac to be less of a headache than the alternatives for personal use and I know many feel the same way. 2. Regarding the whole H.264 verses Theora debate, Steve Jobs is pushing the HTML5 standard as a flash alternative, and while I don't have enough hands on experience with as a method of streaming (seeing as few sites use it as of yet) to offer an educated opinion on how well it works, if the FSF has a problem with the H.264 codec as part of the HTML5 standard specs they should be taking it up with the WHATWG which is the organization responsible for drafting the specs, not Apple. If anything given the proprietary licensing of Flash coupled with the fact that to the best of my knowledge there is no existing free/open development tools for Flash if anyone is being hypocritical here it's the FSF for giving Apple flack for trying to push HTML5 as an open web standard alternative to Flash! As a side note I know people have been phobic about H.264 particularly where license fees are concerned (and I'd be lying if I didn't say I shared some of those concerns) but IMHO I have been using it for video work with both open source and proprietary software both types of which have existed without licensing and revenue problems to date, so if that does become a concern then I expect an alternative (such as Theora) will emerge into widespread usage as necessity dictates but until then, I'm realistic enough to expect the majority of users and developers to push H.264 as a part HTML5 because the majority of users already have it. Personally in the end I think mass usage is still the ultimate standard regardless of what any interest or organization may try to dictate and while I may not always agree with the majority of users and try to educate them about better alternatives to me that's still the true freedom of the web...

Android has a C API. I imagine they ported Gecko via that, and then implemented XUL using Android UI components.

Err:

http://www.android.com/
http://palmwebos.org/
http://www.symbian.org/
http://maemo.org/

You might not be able to publish iPhone apps (ignoring webapps) but it's not the only smartphone on the market.

Not on mine, it doesn't.

I mean, yeah: I could set it up that way. But I don't. It's much, much cleaner, simpler, and to the point to run a real IM client, communicating over TCP/IP, on a computer that thinks it's a phone, than to deal with any IM-to-SMS hodgepodgery.

PalmSource was bought out by the Japanese company Access, which has managed to produce absolutely nothing useful with their Access Linux Platform over the last four years or so.

Meanwhile, the core BeOS/PalmSource developers left to develop Android.

There is no task manager in Android. And Android generally follows the same policy in that background applications are killed (after persisting their state) when OS decides that there are too many running at the same time. The difference is that Android allows applications to spawn their own background threads, but that's about it.

See this and this for more info.

There is no task manager in Android. And Android generally follows the same policy in that background applications are killed (after persisting their state) when OS decides that there are too many running at the same time. The difference is that Android allows applications to spawn their own background threads, but that's about it.

See this and this for more info.

You do know about NDK, right?

And if you happen to be developing native application code for Android using the Android NDK or contributing to the Android OS itself, you will be writing it in C.