Mobile Development SDK Cage Match

Hardware and technical stuff
21

One thing is that we try to be as backwards compatible as possible. This means that a lot of new stuff (for both Android and iOS) we can’t use until 1-2 years after it comes out and enough handsets have moved to make old phones and old OS installs a thing of the past. iOS is a bit better here because typically all phone versions can update to the latest OS and it’s a little bit easier to slip in code that isn’t supported on older devices.

ARC is pretty much all or nothing. Still it’s nice that it’s at least backwards compatible to 4.3 (albeit without true weak pointers) but there’s still a bit of pressure to go back further than that. We’ll probably look at using it at some point after 5.0 comes out but it’s not a priority (I see it more as a convenience feature than something that’s going to fix a lot of bugs, etc.). One thing I don’t like is the dependency on using correct naming. We do use the expected Objective C naming conventions for methods but I just don’t like such a weakly defined language structure.

22

Are you reading what I write? I specifically mentioned Google Search, Maps, GMail, and Chrome as examples of good design from Google. (GMail hasn’t aged well, but I suspect their upcoming redesign should help with that.) Everyone seems to like G+'s design, too.

But other than search, maps, mail, Chrome, and G+, I can’t think of anything that Google’s made that was well-designed and had a UI better than its competition. Except Calendar.

The hell of it is, I am agreeing with you about Android being clunky, but you’re so intent on your nutty “Google can’t do design, and there was nothing special about maps or gmail or search” claim that you can’t let it go with that. If it helps, I will also grant you that Docs has a sucky UI (while being very technically impressive on a functional level).

23

Google’s Maps and Mail innovations, in my mind, were more about the large-scale, high-quality implementation of a persistent, AJAX-y javascript app driving a fully dynamic UI. They had really good js developers for the time, and no legacy implementations standing in the way.

I’d consider them both more engineering innovations than UI innovations. Which isn’t to say they didn’t have good UI – it’s just that the revolution was in how you could finally interact with these apps outside of the usual browser request/response cycle, and it was good.

24

Yay, more drama drama. “OMG, you’re not even reading what I’m writing.” Chill out dude – I’m just disagreeing with you. I know this is the internet but let’s try and raise the level of discourse a bit.

I like GMail, especially the mobile web app version, but I don’t think you’ve really pointed out how it’s great design. Really it’s just a good example of very engineer-driven / spartan design, IMO. Same with Chrome. What makes these guys examples of “great design” as opposed to just, “hey, Google did a decent job with those”?

The hell of it is, I am agreeing with you about Android being clunky, but you’re so intent on your nutty “Google can’t do design, and there was nothing special about maps or gmail or search” claim that you can’t let it go with that.

And now insults.

Google can do design, they’re just not their strength. Not in the sense that design and innovation on user experiences is Apple’s strength. And it’s a cultural thing. Read In the Plex and/or talk to some Google designers (I’ve had the opportunity to talk to a several fwiw). It’s an engineer driven company in the sense that engineers literally overrule designers. Sometimes you get engineers with a good nack for design and it’s certainly not the case that Google’s UI’s are all garbage but at the end of the day, a few subjective examples aside, Google remains a company that excels at search tech and ads and their contribution to mobile, specifically, has little to do with design/innovation/tech.

P.S. at some point are you going to acknowledge the point that Google bought the Google Maps tech?

25

How so? It’s a per translation unit thing. Or are you referring to the ios-version-min stuff here, too? Not sure I understand what you mean, to be honest.

Still it’s nice that it’s at least backwards compatible to 4.3 (albeit without true weak pointers) but there’s still a bit of pressure to go back further than that.

That’s a totally fair point on the versioning. If you’re still wanting to target 4.2 (or earlier, even?), that’s a deal breaker for using ARC, of course. Do you have any sort of (semi)formalized schedule or metrics based system for when you drop support for older versions? That’s not something I have much visibility into.

We’ll probably look at using it at some point after 5.0 comes out but it’s not a priority (I see it more as a convenience feature than something that’s going to fix a lot of bugs, etc.).

It’ll hopefully help take away a bit of the drudgery, even if it doesn’t actually fix bugs. It should make writing clean code much easier when you don’t have to worry about manual retain/release.

Have you tried out the migration tool on your codebase, by any chance?

One thing I don’t like is the dependency on using correct naming. We do use the expected Objective C naming conventions for methods but I just don’t like such a weakly defined language structure.

This is regarding method families, I take it? I can see where you’re coming from. The compiler is reasoning about the code based on things that, until now, weren’t in the language spec. On the other hand, compilers have been doing some of that sort of thing for a long time now, really. strcpy, malloc, and friends all often receive special treatment from a compiler. What distinction(s) here make you uncomfortable?

As a side note to that, does the existence of the objc_method_family attribute help?

26

Yeah, we’re not going to convert our code until we’re ready to go to a min version of 4.3+. We tend to target whatever the min version is that Apple still lets on the store. That’s kind of an old-school mobile dev thing – we’re used to supporting every last device if we can. We could probably be a bit more progressive though, especially since iOS devices can all upgrade to the latest version (on Android if we want to use something in 2.0, for example, that means that there’s literally no path for some older devices to use the app as some devices can’t upgrade). We do have metrics we’re just really conservative with them.

It’s actually nice when Apple bumps the min store version as it gives us an excuse to increase our min version.

Have you tried out the migration tool on your codebase, by any chance?
Not yet no.

This is regarding method families, I take it? I can see where you’re coming from. The compiler is reasoning about the code based on things that, until now, weren’t in the language spec. On the other hand, compilers have been doing some of that sort of thing for a long time now, really. strcpy, malloc, and friends all often receive special treatment from a compiler. What distinction(s) here make you uncomfortable?
Yep, method families being inferred by prefixes is a bit wonky, IMO. Sure, the compiler might optimize certain calls but typically that preserves functionality and misspelling malloc will still at least give me a compile error. I’m a lot less comfortable with something where behavior might be dictated by someone forgetting/typoing the naming convention and yet there will be no obvious compiler error, etc., to let them know that occurred.

obcj_method_family is nice, but IMO doesn’t really solve the problem.

This objection is a bit subjective though. I just like typing conventions to a bit more explicit. I suppose a good work-around would actually be disabling the family inference, requiring every method that retains a reference to be explicitly typed as such, and then to create a macro that’s a little shorter than attribute((objc_method_family(new))).

27

OK. So is it fair to say that if the compiler generated diagnostics for (most) of the errant cases, that would address your primary concern? (technically, anyway. the aesthetics are of course another matter). I’m not sure offhand which cases currently will or will not generate a compile time diagnostic, though. I don’t know if you’ve dug this deeply into it, but do you have any specific examples where you think a diagnostic (be it warning or error) would be helpful but isn’t currently generated?

Relatedly, what’s the behaviour in the scenarios you’re thinking of if the methods are misnamed? Will the code still work correctly but less efficiently? Or are there correctness issues as well?

obcj_method_family is nice, but IMO doesn’t really solve the problem.

This objection is a bit subjective though. I just like typing conventions to a bit more explicit. I suppose a good work-around would actually be disabling the family inference, requiring every method that retains a reference to be explicitly typed as such, and then to create a macro that’s a little shorter than attribute((objc_method_family(new))).

Yeah, that’s the sort of thing I was wondering about. Apple does all sorts of tricks of that sort for the availability macros, for example.

28

So I haven’t tried this in practice but these are some scenarios that, by my current understanding, will be problematic:

[ul]
[li]An engineer creates a function called “newMethodForSomething” and doesn’t realize that this will be treated as part of the “new” family.[/li][li]An engineer accidentally prefixes a function with “ini” (or “iniT”) instead of “init” and it doesn’t behave correctly as an init function. [/li][li]An engineer refactoring code “helpfully” changes a prefix to a method of any family without remembering that this might affect memory retention.[/li][/ul]
It seems like all of these would be solved simply by requiring an explicit keyword, after the method signature, that defined the behavior rather than inferring by name prefix.

29

None of those designs revolutionized anything. They were all improvements on what was already out there. In the case of Chrome, Search and Maps I’d even say we’re just talking about doing exactly the same as others, but with a superior engine underneath. GMail and G+ is cases of reinventing and improving (in some ways, I don’t like GMail at all, but I know I’m a minority there) on stuff invented by others.
Android is the same, only here they fail on the improvement bit compared to iOS. Not by a large margin and I know some people even prefer their way of doing it (cue Timex raving about Widgets), but even if you think Android is better than iOS, you can’t change the fact that iOS was a gamechanger where Android is more of a “Hey, we need one of those mobile OS’ too!”.

30

I’m not going to get sucked into the revolution vs. improvement discussion, because yeah. But what I’ll say is that IE and Firefox today look more like Chrome than they do like the pre-Chrome versions of their browsers; Bing and Yahoo Search look more like turn of the century Google than they do like Alta Vista or Lycos; Mapquest and Yahoo Maps look more like Google Maps circa 2005 than they do like their circa-2004 selves.

It seems to me that if a new product comes into existence, and after its launch every competitor looks and works more like the new product than like their old selves, the new product can fairly be said to have had a revolutionary design. And in fact, that’s precisely what’s being argued (correctly) about the original iPhone.

(By that metric, GMail is actually the non-revolutionary one, because nobody’s really imitated it, oddly enough.)

31

Are folks talking about innovation, engineering, or “design”? Because, to me, engineering and design are one and the same, and that can be either innovative or not.

Gabe seems to be trying to draw some line between engineering and design… when such a line doesn’t exist. Engineering just encompasses a broader range of design then just the outward appearance of some product.

None of those designs revolutionized anything. They were all improvements on what was already out there. In the case of Chrome, Search and Maps I’d even say we’re just talking about doing exactly the same as others, but with a superior engine underneath. GMail and G+ is cases of reinventing and improving (in some ways, I don’t like GMail at all, but I know I’m a minority there) on stuff invented by others.

This is how most stuff comes about though. Technology is improved upon over time. It’s exceedingly rare, if it happens at all, that someone comes up with some great new idea that’s unrelated to existing stuff. Hell, this is one of the foundational principles of our patent system.

(cue Timex raving about Widgets)

WIDGETS!

can’t change the fact that iOS was a gamechanger where Android is more of a “Hey, we need one of those mobile OS’ too!”.

But I think it may be more, due to what we’re seeing in the market.

The fact that Android exploded from non-existence into the most widely used smartphone OS in the market suggests that it’s more than just another mobile OS. Because there were other mobile OS’s, and they didn’t fare as well. Android came out of nowhere, and absolutely crushed RIM’s offering.

I think that Android’s huge success suggests that it’s a little more than just another random mobile OS.

Oh, one more thing…

There’s one innovation that I’ve got on my Xoom, that I still think most people don’t even know about… because I don’t know of any other tablet/phone that has it.

But the little wheel-menu thing that appears when you slide your thumb in from the sides of the screen on the browser, with all the browser navigation stuff? That’s seriously one of the most awesome aspects of the Xoom, and makes its browser rule.

I cannot believe that the iPad doesn’t have this… honestly, I can’t believe that every touchscreen device doesn’t have this.

32

Android is benefiting from a few things.

First (and foremost?) it’s backed by Google, who are a behemoth in the tech world. That can’t be underestimated. Nor can the fact that Google tend to generate a lot of good will because they are, for the most part, A Good Company. It’s available under a very liberal license which has to be a boon and is probably the reason that a lot of what we would have regarded as being ‘feature phones’ in the past are now marketed as low-end smartphones.

I think you can under-estimate how much of Google’s market share is down to people who, for reasons that run the gamut from valid to fucking stupid, wouldn’t be caught dead buying anything with a half-eaten malic fruit on it.

And of course, for the most part it’s a very fine OS.

33

I think you can under-estimate how much of Google’s market share is down to people who, for reasons that run the gamut from valid to fucking stupid, wouldn’t be caught dead buying anything with a half-eaten malic fruit on it.

Eh, I have to think that this number is exceptionally small.

Other than a handful of technogeeks, I don’t think most normal folks have any animosity towards Apple.

34

I said I think you can under-estimate… Yeah, you’re probably right. I know a few people who won’t touch an Apple device with a ten-foot barge-pole but most of them are geeks.

35

Anecdotally, but you really can’t over-estimate how many people walk into a store wanting an iPhone… only cheaper.

36

Android supports live wallpapers, so as far as I’m concerned iOS, Windows Phone and whatever else exists can just be cast aside like the static carcasses they are. All hail the slowly rotating galaxy wallpaper!

One thing that surprises me is that Google haven’t made their own IDE for Android. I know Eclipse and IntelliJ provide good support but neither are optimal for the sole purpose of Android development. I’d genuinely like to see what they would come up with.

37

According to a recent NPD report, 52% of all smartphones sold in the US last quarter was an Android phone. On world-wide basis, Gartner claims Android marketshare last quarter ran at 43%.

Will be interesting to see what impact the iPhone 5 and the rumored cheap iPhone 4 will have.

P.S. Sorry - wrong thread. Moved this elsewhere.

38

The reality is though, that Eclipse is the most widely used Java IDE, and since Android development is essentially Java development, it makes pretty good sense to let folks leverage an IDE that they likely already have on their system.

39

Plus it is easy to build expansions on (even Borland ended up dropping attempts to build their own Java IDE from scratch, and based their JBuilder product on Eclipse). Why reinvent the wheel, when it is so easy to simply expand on a very capable that already exists (and which - despite the impression one might get here - is liked by a lot of developers).

40

Ah… JBuilder… The last standalone JBuilder was probably the best IDE ever made, for any language.

We used to use it until they announced they were discontinuing it… and by the time they reversed course and said they were going to continue it as an eclipse plugin, we had already shifted to eclipse, and then never bothered migrating to the JBuilder plugin. I’ve never used it… how much does it cost these days? I have to assume it’s not quite as awesome as the standalone JBuilder was?