My own research (which involves poking at the dev environment and talking with Android developers, but not actually doing Android development yet) leads me to believe that both you and the person you're responding to are partially right.
You can write very portable apps if you want to. You can write very locked-in apps if you want to. For some developers it's not a problem, and for other developers they're finding that they have to (at least) change the way they think about a lot of stuff.
There is a (weak) analogy to J2ME here. There was a common subset of J2ME, and if you stuck to it, your apps could run on a wide variety of handsets... but they sucked, since that common subset sucked. The best J2ME apps were written for individual handsets.
Nothing I've seen indicates that the Android marketplace is that bad. But it's also not "write once, run everywhere, even without putting any design effort into making that come to pass, regardless of the kind of app you're writing".
For some apps (especially some games), the developers have it stuck in their heads that they must have the background of their main view be based on a pre-rendered bitmap image that's got exactly the same number of pixels as the display it's rendering on. If those folks insist on continuing to think that way, they'll have an awful lot of work to do...
This would be like saying you program for the iphone vs the iphone 3Gs.
You know there are cases where you essentially do, right? It's not common for most apps yet, but if you use the newer OpenGL features on the 3Gs, the app won't run on a 3G or 2G. The iPad takes this to an even greater extreme.
Okay, so you'd rather stamp your feet and swear than participate in a conversation. Did you have a rough day, sweetie? I do hope tomorrow goes better for you.
I also hope you feel better after venting like that. But be aware that it gets boring to read pretty quickly.
How many non-Nintendo titles on the Wii list? How many different companies are represented? How many non-Microsoft titles on the XB360 list? How many different companies are represented? What about the PS3 list?
Presumably you find fault with the argument. I'd be more than happy to look at any data you've got that contradicts it, hints at other explanations for the same data, whatever. Got a handy cite?
Well, it's relevant in that if it turns out nobody is making any money off Android devices, a lot of companies will simply stop making Android devices, and switch to something they can make money from.
Or: the goodness of something doesn't rely on the amount of money you make out of it, unless you are a business that only exists in order to make money. Then, it does.
There's been anecdotal evidence that there isn't as much money to be made writing Android apps as there is to be made writing iPhone apps.
One theory has gone "that's because the user base isn't there yet; when the users show up, the developers will come".
Well. It looks like the users are showing up in numbers that are becoming difficult to ignore. So now it's time to keep a close eye on app developers, and see what happens! Is Android more like the XBox 360 (where a lot of third-party developers make a lot of money), or more like the Wii (where almost nobody but Nintendo ends up making much money)?
It's all going to be very interesting to watch. Yay competition!
Even Microsoft never made us pay money to them just so we could run applications we developed ourselves!
Actually... look up "XNA Creator's Club".
See, there's this hobbyist dev environment for the XBox 360. The dev environment is entirely free! You can download it and install it for free (as long as you run Windows), and run the apps you build on your desktop (as long as you run Windows).
You can even install the code you write on your own XBox! But to do that, you have to have an active membership. Wanna guess how much it costs?
$99/year.
By the way, after you've looked all of that stuff up... go look up how "Windows Phone 7" development is done.
Wow, son, it sure is your week to make aggressive assertions that are so incomplete as to become inaccurate, isn't it?
Tell you what. You seem to be going on and on about what I do or don't know about iPhone programming. This isn't the place to continue that discussion. There's another place we could continue this, where I'd have the freedom to discuss the exact behaviors of the exact APIs that deal with multitasking. So how about you join me over there, and we can pick this back up? Here's the URL:
If you want a starting point for that discussion, here's the source code that I've been sharing with other registered iPhone developers in order to probe the capabilities of various devices running various operating systems. Go into the "Sources" folder and grab the "Runner" application:
I don't expect you'll follow me over there. I expect you'll instead stick to your usual pattern of ignoring 90% of what I wrote, latching on to some concept that doesn't match what's in your head, stamping your feet, getting red in the face, and yelling something incomplete and barely-coherent. In which case this is the last you'll hear from me. But, feel free to prove me wrong!
And do try to calm down a bit, for your own good. Your anger and misplaced contempt really do make you come across as even more stupid than your inaccurate assertions would on their own, and they paint you into a corner that makes it difficult for you to admit the cases in which even you have been able to figure out that you're wrong (which is, I suppose, why you just let those particular subjects drop). If you don't believe that, go try and find a neutral third party and ask them to read this whole back-and-forth, and see what they think.
Would that Block not simply disappear when IPv6 would work?
Yeup. If IPv6 actually worked fine everywhere, this "block" wouldn't be any kind of problem. What this "block" does is, it discourages people from adopting IPv6 until after IPv6 is more reliable than IPv4 (which it isn't, today, and so this "block" actually does discourage IPv6 adoption today).
Modifications to API and system calls do not require a recompile unless the interface to them changes, and if the interface to them changes, you can't simply recompile.
Never used a library that changed the linked interfaces without requiring a change to the source code, by the mechanism of macros in the header files, have you?
Also, did you realize that to relink to a static library, you have to do "the equivalent of typing make" even if none of your code recompiles?
You're the one who has no fucking idea what you're talking about. Thank you for proving it to everyone who's been following along! Bored now.
If you want one example in which doing the equivalent of typing "make" would allow your app to multitask, just go back to MacOS around the time of classic MacOS 6 or so. The multitasking was cooperative, and needed to be supported by each application in order to work properly. If you recompiled your program, the libraries and linkage and such could have the hooks all inserted automatically, enabling much better multitasking support without the programmer changing a single line of code, simply by recompiling and re-linking the application.
Any time you have a multitasking system that's not just a simplistic pure preemptive one, you can improve multitasking by using APIs and system calls that cooperate with the multitasking implementation (even if it's not "cooperative" mulltitasking). A bunch can be accomplished by changing the implementation of a system call. More can be accomplished by changing the code in a shared library. (But a lot of iPhone apps use static linking for a lot of stuff, instead of dynamic linking, as a way to keep apps in their sandboxes.) And even more can be done if the frameworks in use are very standard and are used in standard ways, so calls to new code can be transparently added without changing a line of source code. Exactly as was done when multitasking was added to classic MacOS, and the cooperating functions were inserted into the standard event-handling loop.
You know, the same sort of thing does occur under Unix. Think about I/O libraries. If you're waiting on input from a device (like a serial port), you can poll the thing in a tight loop, you can poll the thing with a "sleep" inside the loop, and you can use a system call that blocks on device I/O. I've seen all three used under Unix, especially back in the 1980s. And sometimes the behavior was chosen within a framework (or "library"), instead of the author's source code. And in those cases, you could get a program that multitasked much more efficiently by simply re-linking to a new version of the library (which could require recompiling, even if you didn't statically link, depending on what changed in the associated header files).
Do you remember those days? Remember writing Unix code that talked with serial ports (terminal software, fax software) that had to run under Ultrix, SunOS, AOS, BSD, and SysV, and using compatibility libraries to make it work? Remember how early versions of the compiled programs could eat astronomical amounts of CPU? Remember how updating the compatibility libraries and typing "make" could cause resource consumption to drop through the floor? Do you remember? Because I do, as my startup company was based around doing pseudo-realtime programming of Unix serial ports.
So. This is all speaking in general terms about how "typing make" actually could enable multitasking in an app without changing a single line of its source code. I can't speak in iPhone-specific terms in this forum for a few months yet -- nobody can (legally).
So, I'm not 100% sure I understand what's going on here. Let's check.
It sounds like the problem is: if you've got a server that according to DNS is available both via IPv6 and IPv4, and the IPv6 address is not working, and the IPv4 address is working, the systems in question will fail to connect to it, even though they could if they'd just fall back to IPv4.
If a given server is IPv6-only, it works fine. If a given server's IPv6 connectivity is more reliable than its IPv4 connectivity, that's also fine. If a given server is IPv4, that's also fine. The problem only manifests when the server is available both via IPv4 and IPv6, and the IPv4 connection is more reliable than the IPv6 connection.
Yes?
And then on top of that, the author observes that on a system reachable both ways, it is typically the case today that the IPv4 version is considerably more reliable than the IPv6 version, and so in practical terms this issue actually does come up in the real world.
Yes? Do I grok, or have I made an error in reading?
Just to follow up: I know some people are baffled that when I discuss competition in the upcoming touchscreen/tablet space, I do mention WP7 in the same breath as iPhone and Android. That's because if Microsoft is smart, they actually have a chance with WP7. This could be their "3.11 for Workgroups" in the handheld/tablet space.
I am sold on the notion that for devices like these targeted at "regular people", you can't just let anyone load any old code on them. You've got to keep apps from interfering with each other, you've got to keep apps sufficiently stable, you've got to keep apps sufficiently well-behaved, and you've got to make sure the user interaction models aren't too surprising (ie. they follow platform UI guidelines). I really to buy that that's necessary for these devices.
And I might be wrong, and I recognize that, and that's why I pay so much attention to Android. Some Android devices are wide open, and others aren't. It'll be interesting to watch.
The iPhone OS is about as locked up as you can get, and it's working.
WP7... WP7 uses XNA (or Silverlight) for app development. Programming on this sort of device has a huge amount in common with programming for a gaming console. And Microsoft's OS for this sort of device uses the same dev environment as the "indie games" marketplace for the XB360.
Now, I have not heard anyone state that they'll be using the same peer-review process for WP7 apps that they use for XNA "indie games". But it's certainly a way to get a lot of the benefits of a closed review process while avoiding some of the most egregious problems, isn't it? Microsoft is already very well positioned to do that if they want to. And if they do it, they could hit the "sweet spot" for openness, with just enough restriction to make the platform really work for end-users coupled with just enough openness to truly unshackle developers. It could be quite exciting to watch.
(Of course, the thing that splashes cold water on my face in all of this is, watching the demos of the WP7 user interface makes my skin crawl. Can't stand it. But I'm willing to allow for the possibility that that's just because I'm not used to it yet, and I'm willing -- in fact eager -- to give it a chance to "wow" me. I very much look forward to 3-way competition between Android, iPhone, and WP7 in the marketplace. Exciting times should be coming up within the next 18 months I hope to have at least one device in each ecosystem and one app available for each within that time frame, so I can really watch.)
On reflection, you're right, I was being sloppy and imprecise with a point that was tangential to the main topic I was discussing. My apologies.
(But I will point out, you are wrong to accuse me of being "so convinced" that every single indie game is developed in C# -- I explicitly wrote "as far as I'm aware", because I was perfectly aware that my information could have been incomplete. Thank you for the very specific pointer for the IronPython example. I have been keeping an eye on XNA for a few years now, contemplating whether or not to "dive in", and that's the first reference I've seen to anything other than C#.)
So, here's the situation as I now understand it, with more precision:
If you just say "XNA", you're being imprecise. There are XNA frameworks. There are asset management tools. There's "XNA Game Studio". There is (was?) "XNA Creator's Club".
It's built on the.Net CLR. That is, at its core there's a VM, similar to the JVM, the "common language runtime" one that.Net uses. The frameworks are available via CLR -- if you want to use them, you need a language that "participates" in the CLR fully, seeing the objects and methods that are available in it.
The frameworks are analogous to the iPhone OS frameworks (Cocoa Touch, Core Foundation, Core Data, et cetera). The "Game Studio" is analogous to Xcode.
Here's the thing that's important to get: the "niche" occupied by the CLR in XNA is occupied by the Objective-C runtime in the iPhone OS. If you use most languages other than Objective-C, you're doing the equivalent of using a language that can't participate fully in the CLR, that can't see objects in it, that can't directly invoke methods on the frameworks exposed through it.
I had thought that C# was the only language in actual real-world use by XNA hobbyists. I will say it's certainly the one I see being discussed the most, documented the most -- heck, the "getting started" instructions I've seen all discuss using "Visual C# 2008 Express". In all the discussions about XNA I've seen or participated in, C# was assumed. But other languages aren't explicitly forbidden, and apparently they do get some use.
That is in fact the situation I'd like to see with Apple, if you're careful to keep the analogy intact. You can use any.Net-ish CLR-ish language with XNA. You should be able to use any non-interpreted language that uses the Objective-C runtime as its runtime for iPhone development.
Now, this isn't in fact a large set of languages right now. The reason C gets included is because Objective-C is pretty much a superset of C. The reason C++ gets included is simply because how trivial it is to link between C and C++. I do not recommend doing much iPhone development in C++ -- the OO systems are not compatible. This is not a way to avoid Objective-C. You end up using both, in order to get any work done, and the objects that the frameworks see and interface with are going to be the Objective-C ones. But you can use C++ for your "model" objects if you're careful, and this is actually valuable because of C++-based computational libraries/frameworks that exist out there.
(This is why things that map between a language's objects and C++ objects would not be sufficient. You're not getting the required Objective-C-like behaviors that way. You don't even get them in C++ itself, and Apple has been mixing C++ and Objective-C for many years now!)
Beyond those, MacRuby is the most obvious one. It actually compiles Ruby, and uses the Objective-C runtime and garbage collector to get its job done. It's also by Apple. There's no reason it shouldn't be supported... except that it's only up to version 0.6 right now.
There is no reason to believe that there is a technical reason behind it. Either the application works, or it doesn't. Thats supposed to be the end of the discussion on the technical aspect of this...
Good heavens, why do you believe that? "It works or it doesn't" is not supposed to be the end of the discussion. Where did that idea come from? If you think that, you don't understand Apple.
"It works" is important. But having every app able to switch to full multitasking support by doing little more than typing "make" once 4.0 comes out is also important. Being able to switch from Arm to x86 or any other CPU architecture by doing little more than typing "make is also important. Running seamlessly on an iPad or "iPhone HD" is also important. Having the unused pieces of your app able to be removed from memory so that background tasks have more space to run in is also important.
Maybe those are not important to a given app developer. Maybe those are not important to a given user.. This is harsh, but none of those folks get a say. They're important enough to Apple to form the kernel of a technical basis for the restrictions. (Restrictions which I've already agreed probably go too far.)
That's totally different because firstly XNA is not a language and secondly the indie game marketplace is not the only way to legitimately get your game out on the console.
Your second point stands. But your first does not -- XNA isn't the equivalent of Objective-C, it's the equivalent of Xcode. I have never heard of anyone succeeding in using any language with XNA other than C#. As far as I'm aware, every single "indie game" (they used to be called "community games") is written in C#.
But yeah. There are other mechanisms for getting stuff on to the XBox. All of them are considerably more expensive than $99 a year (which is what XNA creator's club membership costs), but they do indeed give you considerably more freedom with regard to the technologies you use.
I would like to see Apple do the same thing, where the "baseline" dev kit works the way today's does, and there's something else available to people with Very Deep Pockets who absolutely insist on more freedom. On top of that, I'd like them to add another tier at the hobbyist end of development, with something along the lines of HyperCard, that would be seen as unsuitable for "mass market" applications, but would meet the needs of the folks who just wanted to tinker with the device for their own use.
I know a bunch of people are going to say I'm some kind of fanboy or something, but: there are reasons to believe this restriction is not entirely business-driven. That is, there's reason to believe there's some technical reasoning behind it.
Now, I do believe there are business reasons too. The technical reasons wouldn't be enough to forbid all environments other than Xcode+Objective C. I could see something like MonoTouch being able to meet the actual technical requirements trivially.
But do you know how MonoTouch actually works? The result would not be portable. It would be just as tied to the iPhone as an Xcode/ObjC app, it would simply be using another language.
Apps on the iPhone need a particular application architecture if they're going to perform well. This is true now, but is going to be even more true in the future, when the OS tries to do more complicated things with each app than simply "jump to it when the app starts, and shut it down completely when the app ends".
The same is true on Android by the way. If you want to use Android's frameworks, you have to access it from within their custom JVM. Yes, you can program in C, but your C can't call their frameworks. You write your C using JNI to make your C routines available to the Java code, and some minimum "stub" Java code has to glue your code to all the Android frameworks. And if you want your code to continue running in the background, you have to fork off a "Service" that is essentially the Android version of a daemon.
The same looks to be true of WP7. It looks like you code your UI up as a silverlight or XNA app, and you flow data into it via ActiveSync (I am not clear on all of the details). Each of these platforms requires a completely fundamentally different architecture to write to. You're not going to get true portability across them easily, not and get a decent experience with the app.
So anyway, on the iPhone OS, you need to have your UI broken up into a set of XIB/NIB files, and each "view" needs to have a "view controller" object -- and by "object" I mean something that the on-device Objective-C runtime sees as an Objective-C object. Has to have the semantics of an Objective-C object, and has to support the introspection methods of an Objective-C object (just as Android objects have the semantics of Java objects). If all that is in place, then the OS can (in theory) do stuff like unload UI assets and UI-related objects from the running process, and notice before they're needed (via Obj-C introspection and method interception and stuff), and load them back in before they're missed.
So if you're using MonoTouch, which is basically (from what I read) little more than a way to do Objective-C programming using C# syntax, you could be fine. Your UI assets would still be in those separate XIB/NIB files, your controller objects would be indistinguishable from "raw" Objective-C objects as far as the runtime is concerned, and so on. So stuff like that ought to be permitted. And it won't be portable.
So, Apple could say something more along the lines of: "Here are the rules. Your UI needs to be implemented as a set of XIB/NIB files in these data formats that the OS can inspect in these ways, and that the OS turns into a view hierarchy for your app upon loading. You need to specify connections between those view hierarchies and a bunch of things that behave as if they were plain Objective-C objects with regard to the following (very long) list of introspection mechanisms. References between objects in your code have to permit these sorts of relocation and this sort of serialization. And your callback methods need to behave such-and-such way, and any time we change the ABI for the closure functionality we added as an extension to the C-family languages, you must be able to conform to the possibly-extensive ABI change within less than a week of being informed of it. And and and...".
I see it as an attack on both Firefox and Adobe at the same time.
So, before it looked like if you wanted to reach almost everyone with your content, you had to do HTML5/H.264 and also Flash. If you just did Flash, you left out all the iDevices, and content providers are increasingly unwilling to leave them out. If you just did H.264, you got all the iDevices, Android, almost certainly WP7, and Safari and Chrome on the desktop, and Opera on some desktops. You didn't get Firefox or IE, which meant you didn't get most Windows users, and there's no way content providers are leaving out Windows users.
After this move, HTML5/H.264 will get you just about everyone except the Firefox users.
Content providers have three real choices if they want to get everyone. Doing HTML5/H.264 is essentially mandatory. That leaves out Firefox users. So content providers can (a) tell Firefox users to get a real browser, (b) provide a Flash interface just for Firefox users, or (c) provide an Ogg version in addition to the H.264 one.
Different subsets of the providers will opt for different choices. All three will happen to some extent. As a result, Flash use will go down (but won't be eliminated), and Firefox users will have a less-than-complete browsing experience (unless they relent on the "we won't let you fall back to the OS's built-in codec support" thing).
Actually there are two senses in which it can view 720p video. I'm sure the person you're responding to meant the first.
First, the H.264 playback engine caps out at 720p. Now, almost all playback engines cap out at some level. If you load 720p video files on a first generation iPod Touch, they won't play at all -- it's more than the device can handle. So don't say "of course it can play back a 720p file, every device can play back a 1080p file and just downscale it, that's no big deal". Because that isn't true.
(And yes, there's an advantage to this, if the video doesn't have much going on on the side edges. You can "zoom in" to the video, making it go full screen with the edges clipped, and with a 720p data file you'll get more detail doing this. This could be the case for example if you've got a HD render of "The Philadelphia Story" with Grant/Hepburn, as it was actually filmed in 4:3, not 16:9.)
But, second, the iPad has video-out capabilities. I picked up the "dock port to VGA" adapter for mine. When I hook it up to the HDTV in my living room, and run a little program I wrote that queries the OS for a list of attached screens and their display characteristics, know what? I have full access to full 720p resolution out that display port. So an iPad tucked behind an HDTV that it's connected to can indeed drive a full genuine 720p display.
(But I'm sure that's not what the person you were responding to meant.)
Even with the contrived numbers you have given, fixing the button will quickly pay for itself when compared to the alternative.
No. You don't get to just assert that. It's not always true.
The cost/benefit analysis has to happen, and with realistic numbers. You don't get to just assert "it will pay for itself" and wave your hands. You have to use real numbers and do a real analysis. And sometimes the answer really is "it doesn't pay to convert yet".
When the alternative is $11 in earnings every time a button is pressed, how is the malfunctioning system worth using? Fixing the button will increase profits by 120%. Even if the fix is expensive, it will quickly pay for itself.
Let's plug some numbers in. If the fix costs $300,000, and the button is throttled so it can only be pressed three times a day, how long will it take for the fix to pay for itself?
(Yes, it's a contrived example. The point is, "the fix will quickly pay for itself" is already going to be taken into account, and very often is simply not true That's why you do a cost/benefit analysis.)
A perfectly secure system that doesn't do anything is useless. But an insecure system that malfunctions and loses $5 with a 50% chance time you press a button is still worth using if it earns $11 when it doesn't malfunction.
There's a cost/benefit analysis going on. For a lot of businesses, even with the insecurities and incompatibilities, the result of that cost/benefit analysis is "keep running IE6". The solution really is to take those business functions that only work on IE6 and update them so they work with newer browsers... as long as the cost savings of moving to a newer browser exceeds the cost of that mitigation effort.
When it doesn't, you end up deciding to keep running IE6. On purpose. Without being wrong.
I know, I know, they are publicly traded & would never cut off that revenue stream.
Forget any consideration of whether or not they'd cut off their revenue stream.
Go to finance.google.com and do some research on Adobe and Apple.
Do you see that Adobe's market cap is less than $19 billion?
Do you know that Apple has a "war chest" of over $40 billion sitting around?
Basically, Apple could outright buy a controlling interest in Adobe for less than 1/4th of the cash they have in reserve. Less than 25% of the pile of money Apple is just sitting on could buy 51% of Adobe's stock.
If Adobe made a move like you suggest, and if Apple believed there was the remotest chance they'd be harmed by it... come on, what do you really think would happen?
Adobe has absolutely no power here beyond rhetoric, publicity, propaganda, whatever you'd like to call it. Now, that power can be very strong, if they use it wisely. Let's see if they do.
Ah, see, if you were "correctly" set up in the same AD realm as the SharePoint server, when IIS said "hey, you, authenticate via SPNEGO please", your clients would say "okay, here's my kerberos ticket, go to town". Regardless of how many times they asked for it.
But if you're not in the right realm or don't have a kerberos ticket or whatever, the SPNEGO falls back from Kerberos to NTLM (almost the same as "digest auth" in theory, just completely incompatible with it in practice). So, you're getting the non-Microsoft sort of experience, at least in part. But at least you're also getting the WebDAV and ActiveX "features".
Short of converting everything to Google Docs, you've got to let someone download the PPT/XLS/DOC/PDF at some point.
No, you don't. That's what WebDAV is for. MacOS supports it just fine, it's just that SharePoint doesn't expose its WebDAV URLs to anything but Windows.
I don't have any problem suggesting sharepoint, As long as it's not somewhere I have to work.
I do, if it's a mixed windows/mac shop. The problem is, while many basic features work in a cross-platform way, the more sophisticated features don't.
And I'm not just talking about "sophisticated" in terms of "power user". I'm talking about stuff like, if you're on Windows and in an AD domain, having single sign-on from your desktop "just work", while the MacOS folks have to type their username/password into the browser as if they were using basic auth (they're using SPNEGO-negotiated-NTLM, but the user experience is the same). And I'm talking about Windows users clicking on a Word document to have Word open the file in-place via WebDAV and save it back there without a separate upload step, while MacOS users have to do explicit "download, edit, save, upload" steps (which is one of the things a good CMS should help reduce, since in practice that inevitably results in multiple versions scattered all over and loss of control of which version is "master", for example when someone decides "oh, I already downloaded that, I don't need to again, let me just add another edit", and does an upload that trashes someone else's work).
Technically you can get by with SharePoint in a shop that's not 100% Windows. But don't try.
Slashdot Mirror
My own research (which involves poking at the dev environment and talking with Android developers, but not actually doing Android development yet) leads me to believe that both you and the person you're responding to are partially right.
You can write very portable apps if you want to. You can write very locked-in apps if you want to. For some developers it's not a problem, and for other developers they're finding that they have to (at least) change the way they think about a lot of stuff.
There is a (weak) analogy to J2ME here. There was a common subset of J2ME, and if you stuck to it, your apps could run on a wide variety of handsets... but they sucked, since that common subset sucked. The best J2ME apps were written for individual handsets.
Nothing I've seen indicates that the Android marketplace is that bad. But it's also not "write once, run everywhere, even without putting any design effort into making that come to pass, regardless of the kind of app you're writing".
For some apps (especially some games), the developers have it stuck in their heads that they must have the background of their main view be based on a pre-rendered bitmap image that's got exactly the same number of pixels as the display it's rendering on. If those folks insist on continuing to think that way, they'll have an awful lot of work to do...
You know there are cases where you essentially do, right? It's not common for most apps yet, but if you use the newer OpenGL features on the 3Gs, the app won't run on a 3G or 2G. The iPad takes this to an even greater extreme.
Okay, so you'd rather stamp your feet and swear than participate in a conversation. Did you have a rough day, sweetie? I do hope tomorrow goes better for you.
I also hope you feel better after venting like that. But be aware that it gets boring to read pretty quickly.
Where the FUCK did you come up with that garbage?
From watching NPD numbers, paying attention to the gaming industry press, stuff like that.
Did you follow how "Dead Space Extraction" did on the Wii compared to "Dead Space" on the XB360?
Heck, just compare this list:
http://en.wikipedia.org/wiki/List_of_best-selling_video_games#Wii
to this one:
http://en.wikipedia.org/wiki/List_of_best-selling_video_games#Xbox_360
and this one:
http://en.wikipedia.org/wiki/List_of_best-selling_video_games#PlayStation_3
How many non-Nintendo titles on the Wii list? How many different companies are represented? How many non-Microsoft titles on the XB360 list? How many different companies are represented? What about the PS3 list?
Presumably you find fault with the argument. I'd be more than happy to look at any data you've got that contradicts it, hints at other explanations for the same data, whatever. Got a handy cite?
How is it relevant ?
Well, it's relevant in that if it turns out nobody is making any money off Android devices, a lot of companies will simply stop making Android devices, and switch to something they can make money from.
Or: the goodness of something doesn't rely on the amount of money you make out of it, unless you are a business that only exists in order to make money. Then, it does.
There's been anecdotal evidence that there isn't as much money to be made writing Android apps as there is to be made writing iPhone apps.
One theory has gone "that's because the user base isn't there yet; when the users show up, the developers will come".
Well. It looks like the users are showing up in numbers that are becoming difficult to ignore. So now it's time to keep a close eye on app developers, and see what happens! Is Android more like the XBox 360 (where a lot of third-party developers make a lot of money), or more like the Wii (where almost nobody but Nintendo ends up making much money)?
It's all going to be very interesting to watch. Yay competition!
Actually... look up "XNA Creator's Club".
See, there's this hobbyist dev environment for the XBox 360. The dev environment is entirely free! You can download it and install it for free (as long as you run Windows), and run the apps you build on your desktop (as long as you run Windows).
You can even install the code you write on your own XBox! But to do that, you have to have an active membership. Wanna guess how much it costs?
$99/year.
By the way, after you've looked all of that stuff up... go look up how "Windows Phone 7" development is done.
Wow, son, it sure is your week to make aggressive assertions that are so incomplete as to become inaccurate, isn't it?
Tell you what. You seem to be going on and on about what I do or don't know about iPhone programming. This isn't the place to continue that discussion. There's another place we could continue this, where I'd have the freedom to discuss the exact behaviors of the exact APIs that deal with multitasking. So how about you join me over there, and we can pick this back up? Here's the URL:
https://devforums.apple.com/community/iphone
Here is how to find me over there:
https://devforums.apple.com/people/dfjdejulio
If you want a starting point for that discussion, here's the source code that I've been sharing with other registered iPhone developers in order to probe the capabilities of various devices running various operating systems. Go into the "Sources" folder and grab the "Runner" application:
http://public.me.com/dd26
And here's the thread in which the discussion of that source code (and its output) has been occurring:
https://devforums.apple.com/message/198165
I don't expect you'll follow me over there. I expect you'll instead stick to your usual pattern of ignoring 90% of what I wrote, latching on to some concept that doesn't match what's in your head, stamping your feet, getting red in the face, and yelling something incomplete and barely-coherent. In which case this is the last you'll hear from me. But, feel free to prove me wrong!
And do try to calm down a bit, for your own good. Your anger and misplaced contempt really do make you come across as even more stupid than your inaccurate assertions would on their own, and they paint you into a corner that makes it difficult for you to admit the cases in which even you have been able to figure out that you're wrong (which is, I suppose, why you just let those particular subjects drop). If you don't believe that, go try and find a neutral third party and ask them to read this whole back-and-forth, and see what they think.
Would that Block not simply disappear when IPv6 would work?
Yeup. If IPv6 actually worked fine everywhere, this "block" wouldn't be any kind of problem. What this "block" does is, it discourages people from adopting IPv6 until after IPv6 is more reliable than IPv4 (which it isn't, today, and so this "block" actually does discourage IPv6 adoption today).
Modifications to API and system calls do not require a recompile unless the interface to them changes, and if the interface to them changes, you can't simply recompile.
Never used a library that changed the linked interfaces without requiring a change to the source code, by the mechanism of macros in the header files, have you?
Also, did you realize that to relink to a static library, you have to do "the equivalent of typing make" even if none of your code recompiles?
You're the one who has no fucking idea what you're talking about. Thank you for proving it to everyone who's been following along! Bored now.
Well. You're not very imaginitive, are you?
If you want one example in which doing the equivalent of typing "make" would allow your app to multitask, just go back to MacOS around the time of classic MacOS 6 or so. The multitasking was cooperative, and needed to be supported by each application in order to work properly. If you recompiled your program, the libraries and linkage and such could have the hooks all inserted automatically, enabling much better multitasking support without the programmer changing a single line of code, simply by recompiling and re-linking the application.
Any time you have a multitasking system that's not just a simplistic pure preemptive one, you can improve multitasking by using APIs and system calls that cooperate with the multitasking implementation (even if it's not "cooperative" mulltitasking). A bunch can be accomplished by changing the implementation of a system call. More can be accomplished by changing the code in a shared library. (But a lot of iPhone apps use static linking for a lot of stuff, instead of dynamic linking, as a way to keep apps in their sandboxes.) And even more can be done if the frameworks in use are very standard and are used in standard ways, so calls to new code can be transparently added without changing a line of source code. Exactly as was done when multitasking was added to classic MacOS, and the cooperating functions were inserted into the standard event-handling loop.
You know, the same sort of thing does occur under Unix. Think about I/O libraries. If you're waiting on input from a device (like a serial port), you can poll the thing in a tight loop, you can poll the thing with a "sleep" inside the loop, and you can use a system call that blocks on device I/O. I've seen all three used under Unix, especially back in the 1980s. And sometimes the behavior was chosen within a framework (or "library"), instead of the author's source code. And in those cases, you could get a program that multitasked much more efficiently by simply re-linking to a new version of the library (which could require recompiling, even if you didn't statically link, depending on what changed in the associated header files).
Do you remember those days? Remember writing Unix code that talked with serial ports (terminal software, fax software) that had to run under Ultrix, SunOS, AOS, BSD, and SysV, and using compatibility libraries to make it work? Remember how early versions of the compiled programs could eat astronomical amounts of CPU? Remember how updating the compatibility libraries and typing "make" could cause resource consumption to drop through the floor? Do you remember? Because I do, as my startup company was based around doing pseudo-realtime programming of Unix serial ports.
So. This is all speaking in general terms about how "typing make" actually could enable multitasking in an app without changing a single line of its source code. I can't speak in iPhone-specific terms in this forum for a few months yet -- nobody can (legally).
So, I'm not 100% sure I understand what's going on here. Let's check.
It sounds like the problem is: if you've got a server that according to DNS is available both via IPv6 and IPv4, and the IPv6 address is not working, and the IPv4 address is working, the systems in question will fail to connect to it, even though they could if they'd just fall back to IPv4.
If a given server is IPv6-only, it works fine. If a given server's IPv6 connectivity is more reliable than its IPv4 connectivity, that's also fine. If a given server is IPv4, that's also fine. The problem only manifests when the server is available both via IPv4 and IPv6, and the IPv4 connection is more reliable than the IPv6 connection.
Yes?
And then on top of that, the author observes that on a system reachable both ways, it is typically the case today that the IPv4 version is considerably more reliable than the IPv6 version, and so in practical terms this issue actually does come up in the real world.
Yes? Do I grok, or have I made an error in reading?
Just to follow up: I know some people are baffled that when I discuss competition in the upcoming touchscreen/tablet space, I do mention WP7 in the same breath as iPhone and Android. That's because if Microsoft is smart, they actually have a chance with WP7. This could be their "3.11 for Workgroups" in the handheld/tablet space.
I am sold on the notion that for devices like these targeted at "regular people", you can't just let anyone load any old code on them. You've got to keep apps from interfering with each other, you've got to keep apps sufficiently stable, you've got to keep apps sufficiently well-behaved, and you've got to make sure the user interaction models aren't too surprising (ie. they follow platform UI guidelines). I really to buy that that's necessary for these devices.
And I might be wrong, and I recognize that, and that's why I pay so much attention to Android. Some Android devices are wide open, and others aren't. It'll be interesting to watch.
The iPhone OS is about as locked up as you can get, and it's working.
WP7... WP7 uses XNA (or Silverlight) for app development. Programming on this sort of device has a huge amount in common with programming for a gaming console. And Microsoft's OS for this sort of device uses the same dev environment as the "indie games" marketplace for the XB360.
Now, I have not heard anyone state that they'll be using the same peer-review process for WP7 apps that they use for XNA "indie games". But it's certainly a way to get a lot of the benefits of a closed review process while avoiding some of the most egregious problems, isn't it? Microsoft is already very well positioned to do that if they want to. And if they do it, they could hit the "sweet spot" for openness, with just enough restriction to make the platform really work for end-users coupled with just enough openness to truly unshackle developers. It could be quite exciting to watch.
(Of course, the thing that splashes cold water on my face in all of this is, watching the demos of the WP7 user interface makes my skin crawl. Can't stand it. But I'm willing to allow for the possibility that that's just because I'm not used to it yet, and I'm willing -- in fact eager -- to give it a chance to "wow" me. I very much look forward to 3-way competition between Android, iPhone, and WP7 in the marketplace. Exciting times should be coming up within the next 18 months I hope to have at least one device in each ecosystem and one app available for each within that time frame, so I can really watch.)
On reflection, you're right, I was being sloppy and imprecise with a point that was tangential to the main topic I was discussing. My apologies.
(But I will point out, you are wrong to accuse me of being "so convinced" that every single indie game is developed in C# -- I explicitly wrote "as far as I'm aware", because I was perfectly aware that my information could have been incomplete. Thank you for the very specific pointer for the IronPython example. I have been keeping an eye on XNA for a few years now, contemplating whether or not to "dive in", and that's the first reference I've seen to anything other than C#.)
So, here's the situation as I now understand it, with more precision:
If you just say "XNA", you're being imprecise. There are XNA frameworks. There are asset management tools. There's "XNA Game Studio". There is (was?) "XNA Creator's Club".
It's built on the .Net CLR. That is, at its core there's a VM, similar to the JVM, the "common language runtime" one that .Net uses. The frameworks are available via CLR -- if you want to use them, you need a language that "participates" in the CLR fully, seeing the objects and methods that are available in it.
The frameworks are analogous to the iPhone OS frameworks (Cocoa Touch, Core Foundation, Core Data, et cetera). The "Game Studio" is analogous to Xcode.
Here's the thing that's important to get: the "niche" occupied by the CLR in XNA is occupied by the Objective-C runtime in the iPhone OS. If you use most languages other than Objective-C, you're doing the equivalent of using a language that can't participate fully in the CLR, that can't see objects in it, that can't directly invoke methods on the frameworks exposed through it.
I had thought that C# was the only language in actual real-world use by XNA hobbyists. I will say it's certainly the one I see being discussed the most, documented the most -- heck, the "getting started" instructions I've seen all discuss using "Visual C# 2008 Express". In all the discussions about XNA I've seen or participated in, C# was assumed. But other languages aren't explicitly forbidden, and apparently they do get some use.
That is in fact the situation I'd like to see with Apple, if you're careful to keep the analogy intact. You can use any .Net-ish CLR-ish language with XNA. You should be able to use any non-interpreted language that uses the Objective-C runtime as its runtime for iPhone development.
Now, this isn't in fact a large set of languages right now. The reason C gets included is because Objective-C is pretty much a superset of C. The reason C++ gets included is simply because how trivial it is to link between C and C++. I do not recommend doing much iPhone development in C++ -- the OO systems are not compatible. This is not a way to avoid Objective-C. You end up using both, in order to get any work done, and the objects that the frameworks see and interface with are going to be the Objective-C ones. But you can use C++ for your "model" objects if you're careful, and this is actually valuable because of C++-based computational libraries/frameworks that exist out there.
(This is why things that map between a language's objects and C++ objects would not be sufficient. You're not getting the required Objective-C-like behaviors that way. You don't even get them in C++ itself, and Apple has been mixing C++ and Objective-C for many years now!)
Beyond those, MacRuby is the most obvious one. It actually compiles Ruby, and uses the Objective-C runtime and garbage collector to get its job done. It's also by Apple. There's no reason it shouldn't be supported... except that it's only up to version 0.6 right now.
http://www.macruby.org/
The limited information I have regarding MonoTouch leads me to believe something similar i
Good heavens, why do you believe that? "It works or it doesn't" is not supposed to be the end of the discussion. Where did that idea come from? If you think that, you don't understand Apple.
"It works" is important. But having every app able to switch to full multitasking support by doing little more than typing "make" once 4.0 comes out is also important. Being able to switch from Arm to x86 or any other CPU architecture by doing little more than typing "make is also important. Running seamlessly on an iPad or "iPhone HD" is also important. Having the unused pieces of your app able to be removed from memory so that background tasks have more space to run in is also important.
Maybe those are not important to a given app developer. Maybe those are not important to a given user.. This is harsh, but none of those folks get a say. They're important enough to Apple to form the kernel of a technical basis for the restrictions. (Restrictions which I've already agreed probably go too far.)
Your second point stands. But your first does not -- XNA isn't the equivalent of Objective-C, it's the equivalent of Xcode. I have never heard of anyone succeeding in using any language with XNA other than C#. As far as I'm aware, every single "indie game" (they used to be called "community games") is written in C#.
http://en.wikipedia.org/wiki/Microsoft_XNA
But yeah. There are other mechanisms for getting stuff on to the XBox. All of them are considerably more expensive than $99 a year (which is what XNA creator's club membership costs), but they do indeed give you considerably more freedom with regard to the technologies you use.
I would like to see Apple do the same thing, where the "baseline" dev kit works the way today's does, and there's something else available to people with Very Deep Pockets who absolutely insist on more freedom. On top of that, I'd like them to add another tier at the hobbyist end of development, with something along the lines of HyperCard, that would be seen as unsuitable for "mass market" applications, but would meet the needs of the folks who just wanted to tinker with the device for their own use.
I know a bunch of people are going to say I'm some kind of fanboy or something, but: there are reasons to believe this restriction is not entirely business-driven. That is, there's reason to believe there's some technical reasoning behind it.
Now, I do believe there are business reasons too. The technical reasons wouldn't be enough to forbid all environments other than Xcode+Objective C. I could see something like MonoTouch being able to meet the actual technical requirements trivially.
But do you know how MonoTouch actually works? The result would not be portable. It would be just as tied to the iPhone as an Xcode/ObjC app, it would simply be using another language.
Apps on the iPhone need a particular application architecture if they're going to perform well. This is true now, but is going to be even more true in the future, when the OS tries to do more complicated things with each app than simply "jump to it when the app starts, and shut it down completely when the app ends".
The same is true on Android by the way. If you want to use Android's frameworks, you have to access it from within their custom JVM. Yes, you can program in C, but your C can't call their frameworks. You write your C using JNI to make your C routines available to the Java code, and some minimum "stub" Java code has to glue your code to all the Android frameworks. And if you want your code to continue running in the background, you have to fork off a "Service" that is essentially the Android version of a daemon.
The same looks to be true of WP7. It looks like you code your UI up as a silverlight or XNA app, and you flow data into it via ActiveSync (I am not clear on all of the details). Each of these platforms requires a completely fundamentally different architecture to write to. You're not going to get true portability across them easily, not and get a decent experience with the app.
So anyway, on the iPhone OS, you need to have your UI broken up into a set of XIB/NIB files, and each "view" needs to have a "view controller" object -- and by "object" I mean something that the on-device Objective-C runtime sees as an Objective-C object. Has to have the semantics of an Objective-C object, and has to support the introspection methods of an Objective-C object (just as Android objects have the semantics of Java objects). If all that is in place, then the OS can (in theory) do stuff like unload UI assets and UI-related objects from the running process, and notice before they're needed (via Obj-C introspection and method interception and stuff), and load them back in before they're missed.
So if you're using MonoTouch, which is basically (from what I read) little more than a way to do Objective-C programming using C# syntax, you could be fine. Your UI assets would still be in those separate XIB/NIB files, your controller objects would be indistinguishable from "raw" Objective-C objects as far as the runtime is concerned, and so on. So stuff like that ought to be permitted. And it won't be portable.
So, Apple could say something more along the lines of: "Here are the rules. Your UI needs to be implemented as a set of XIB/NIB files in these data formats that the OS can inspect in these ways, and that the OS turns into a view hierarchy for your app upon loading. You need to specify connections between those view hierarchies and a bunch of things that behave as if they were plain Objective-C objects with regard to the following (very long) list of introspection mechanisms. References between objects in your code have to permit these sorts of relocation and this sort of serialization. And your callback methods need to behave such-and-such way, and any time we change the ABI for the closure functionality we added as an extension to the C-family languages, you must be able to conform to the possibly-extensive ABI change within less than a week of being informed of it. And and and...".
You end up with a very very long li
I see it as an attack on both Firefox and Adobe at the same time.
So, before it looked like if you wanted to reach almost everyone with your content, you had to do HTML5/H.264 and also Flash. If you just did Flash, you left out all the iDevices, and content providers are increasingly unwilling to leave them out. If you just did H.264, you got all the iDevices, Android, almost certainly WP7, and Safari and Chrome on the desktop, and Opera on some desktops. You didn't get Firefox or IE, which meant you didn't get most Windows users, and there's no way content providers are leaving out Windows users.
After this move, HTML5/H.264 will get you just about everyone except the Firefox users.
Content providers have three real choices if they want to get everyone. Doing HTML5/H.264 is essentially mandatory. That leaves out Firefox users. So content providers can (a) tell Firefox users to get a real browser, (b) provide a Flash interface just for Firefox users, or (c) provide an Ogg version in addition to the H.264 one.
Different subsets of the providers will opt for different choices. All three will happen to some extent. As a result, Flash use will go down (but won't be eliminated), and Firefox users will have a less-than-complete browsing experience (unless they relent on the "we won't let you fall back to the OS's built-in codec support" thing).
Two birds, one cup^H^H^Hstone.
Actually there are two senses in which it can view 720p video. I'm sure the person you're responding to meant the first.
First, the H.264 playback engine caps out at 720p. Now, almost all playback engines cap out at some level. If you load 720p video files on a first generation iPod Touch, they won't play at all -- it's more than the device can handle. So don't say "of course it can play back a 720p file, every device can play back a 1080p file and just downscale it, that's no big deal". Because that isn't true.
(And yes, there's an advantage to this, if the video doesn't have much going on on the side edges. You can "zoom in" to the video, making it go full screen with the edges clipped, and with a 720p data file you'll get more detail doing this. This could be the case for example if you've got a HD render of "The Philadelphia Story" with Grant/Hepburn, as it was actually filmed in 4:3, not 16:9.)
But, second, the iPad has video-out capabilities. I picked up the "dock port to VGA" adapter for mine. When I hook it up to the HDTV in my living room, and run a little program I wrote that queries the OS for a list of attached screens and their display characteristics, know what? I have full access to full 720p resolution out that display port. So an iPad tucked behind an HDTV that it's connected to can indeed drive a full genuine 720p display.
(But I'm sure that's not what the person you were responding to meant.)
No. You don't get to just assert that. It's not always true.
The cost/benefit analysis has to happen, and with realistic numbers. You don't get to just assert "it will pay for itself" and wave your hands. You have to use real numbers and do a real analysis. And sometimes the answer really is "it doesn't pay to convert yet".
When the alternative is $11 in earnings every time a button is pressed, how is the malfunctioning system worth using? Fixing the button will increase profits by 120%. Even if the fix is expensive, it will quickly pay for itself.
Let's plug some numbers in. If the fix costs $300,000, and the button is throttled so it can only be pressed three times a day, how long will it take for the fix to pay for itself?
(Yes, it's a contrived example. The point is, "the fix will quickly pay for itself" is already going to be taken into account, and very often is simply not true That's why you do a cost/benefit analysis.)
Yes! It simply doesn't meaneverything.
A perfectly secure system that doesn't do anything is useless. But an insecure system that malfunctions and loses $5 with a 50% chance time you press a button is still worth using if it earns $11 when it doesn't malfunction.
There's a cost/benefit analysis going on. For a lot of businesses, even with the insecurities and incompatibilities, the result of that cost/benefit analysis is "keep running IE6". The solution really is to take those business functions that only work on IE6 and update them so they work with newer browsers... as long as the cost savings of moving to a newer browser exceeds the cost of that mitigation effort.
When it doesn't, you end up deciding to keep running IE6. On purpose. Without being wrong.
Forget any consideration of whether or not they'd cut off their revenue stream.
Go to finance.google.com and do some research on Adobe and Apple.
Do you see that Adobe's market cap is less than $19 billion?
Do you know that Apple has a "war chest" of over $40 billion sitting around?
Basically, Apple could outright buy a controlling interest in Adobe for less than 1/4th of the cash they have in reserve. Less than 25% of the pile of money Apple is just sitting on could buy 51% of Adobe's stock.
If Adobe made a move like you suggest, and if Apple believed there was the remotest chance they'd be harmed by it... come on, what do you really think would happen?
Adobe has absolutely no power here beyond rhetoric, publicity, propaganda, whatever you'd like to call it. Now, that power can be very strong, if they use it wisely. Let's see if they do.
That's funny...
Ah, see, if you were "correctly" set up in the same AD realm as the SharePoint server, when IIS said "hey, you, authenticate via SPNEGO please", your clients would say "okay, here's my kerberos ticket, go to town". Regardless of how many times they asked for it.
But if you're not in the right realm or don't have a kerberos ticket or whatever, the SPNEGO falls back from Kerberos to NTLM (almost the same as "digest auth" in theory, just completely incompatible with it in practice). So, you're getting the non-Microsoft sort of experience, at least in part. But at least you're also getting the WebDAV and ActiveX "features".
Short of converting everything to Google Docs, you've got to let someone download the PPT/XLS/DOC/PDF at some point.
No, you don't. That's what WebDAV is for. MacOS supports it just fine, it's just that SharePoint doesn't expose its WebDAV URLs to anything but Windows.
I don't have any problem suggesting sharepoint, As long as it's not somewhere I have to work.
I do, if it's a mixed windows/mac shop. The problem is, while many basic features work in a cross-platform way, the more sophisticated features don't.
And I'm not just talking about "sophisticated" in terms of "power user". I'm talking about stuff like, if you're on Windows and in an AD domain, having single sign-on from your desktop "just work", while the MacOS folks have to type their username/password into the browser as if they were using basic auth (they're using SPNEGO-negotiated-NTLM, but the user experience is the same). And I'm talking about Windows users clicking on a Word document to have Word open the file in-place via WebDAV and save it back there without a separate upload step, while MacOS users have to do explicit "download, edit, save, upload" steps (which is one of the things a good CMS should help reduce, since in practice that inevitably results in multiple versions scattered all over and loss of control of which version is "master", for example when someone decides "oh, I already downloaded that, I don't need to again, let me just add another edit", and does an upload that trashes someone else's work).
Technically you can get by with SharePoint in a shop that's not 100% Windows. But don't try.