A few days of programming on iOS and Android illustrates a vast difference.
51–60 of 97 posts
Re: A few days of programming on iOS and Android illustrates a vast difference.
#52Well you're new to Android so things seem weird at first. It's all a matter of picking up the underlying concepts. To be fair ObjC and Cocoa looks for most Java devs like voodoo, but once you get it it becomes easier, too.
Exactly. This article was completely one-sided. He also failed to see the huge amount of community support there is for Android developers too. There's so much information inside multiple forums you would almost never be unable to find an answer to a problem.
Re: A few days of programming on iOS and Android illustrates a vast difference.
#53Earlier quoted context omitted.
Just a word of advice on Android, polish your app really well before launch. The Android Market comment system is relentless. If you don't have a smashingly nice app out of the gate, you'll probably get a couple 1-star "sucks"/"rubbish" reviews before you can finish your post-launch exhale.
This is interesting because I, having no knowledge of the Android market but a lot of knowledge of development in general, would give the exact opposite advice! In general I think it's agreed that the best thing to do is release, and then tweak. If the Android Market punishes people that do this then I think that's a very real problem with the market that will directly lead to poorer quality software.
Once an app is a month or two old, even if it's well rated and doing decent, it can crash in the rankings and get buried under thousands of other apps, even if it has a lot of enthusiastic fans. And it seems like this happens simply if people don't download it ENOUGH -- if it loses momentum, you're toast.
Re: A few days of programming on iOS and Android illustrates a vast difference.
#54Counterpoint: I just began developing my first Android app a few days ago, a turn-based strategy game. I've only had an Android device for a month or so so the platform is relatively new to me, and I didn't even know Java (although, to be fair, I knew C# fairly well a couple years ago, which is arguably the same thing plus type inference.) In a few days, with relatively few problems, I was able to build an app and I'…
I prefer using and making software for iOS over Android but I think you're right. Cocoa programming requires a lot of up front knowledge about their design patterns and tools. It's no small undertaking for someone to learn about KVO, delegate pattern (so simple but confuses people for some reason, I think it's the name), MVC, and then add actions and outlets, resizing masks, and all the other unique things to Xcode/I…
I don't really have anything bad to say about WPF but when I first got my hands on UIKit and Objective-C I fell in love.
In WPF you can do anything and customize everything. UIKit is Apple's magical black box but it will get you like 80-90% of the way to your goal so you don't need to engineer everything like I did with WPF. Couple that with Foundation and their other great frameworks like CoreLocation and so much boilerplate code seems to be hidden behind Apple's walls.
I'm also probably in the minority but I like the verboseness of Objective-C and the dynamic nature of it. Honestly it is a small thing but not having to put null pointer checks all over my code is the thing about the language I love the most.
Re: A few days of programming on iOS and Android illustrates a vast difference.
#55Earlier quoted context omitted.
Just a point that needs clarification: how is any of this comment relevant to the points raised in the OP? That is, how does this help against the fact that Android has: * A much more complex set of (good!) abstractions that are poorly documented; * and, if I might add alongside the OP, requires a much higher workload in terms of code length and complexity, debugging, device configuration management and tools for wha…
Could you give me an example of exactly why the claims you've made are true? Why would your app need twice as much code? Why is using the Android ui designer so much harder than iOS's equiv? What is so undocumented about IBinder? It's basic IPC? I would really like to hear reasons, not abbreviations.
Re: A few days of programming on iOS and Android illustrates a vast difference.
#56Counterpoint: I just began developing my first Android app a few days ago, a turn-based strategy game. I've only had an Android device for a month or so so the platform is relatively new to me, and I didn't even know Java (although, to be fair, I knew C# fairly well a couple years ago, which is arguably the same thing plus type inference.) In a few days, with relatively few problems, I was able to build an app and I'…
Every time I turned around, the Android platform surprised me. In a bad way. Full disclosure: I'm also not a Java fan, and think it was a completely brain-dead idea to make Java the first-class API. I'm certainly not a Microsoft fan, but even C#/Mono would have been better (not that I know any C#), if only so they wouldn't have had to waste time reimplementing the VM for licensing reasons. But it's not Java that I had a hard time with.
I've developed games on 12 different hardware/software platforms. There are so many things missing and/or broken about the way Android does things that I feel embarrassed for Google. Some of those things have subsequently been fixed, but many haven't, and some have been ignored in the bug database for YEARS now. A LOT of those things wouldn't have been problems if they didn't have so many layers between the app and the hardware (Java being one of those layers, but not the only problem).
As you say, it's really Not That Hard to just throw a simple app together that does what it needs to. Intents and Services are also ABSOLUTELY not the problem. The developer who wrote the original article didn't read enough of the docs or the right docs, or isn't as smart as he thinks he is -- the concept of Intents is not rocket science. The application lifecycle isn't even hard to understand -- it's laid out in the intro docs pretty clearly.
If only Android actually DID what those docs said, things would be a lot easier for a game developer. In fact, an "app" can be stopped and then a new one started before the old one actually receives its shut-down message. In the same (Linux) process -- so any native code with static data is still sitting around. One of many annoying problems I ran into.
I think the core mistake of almost every new platform is one of ego. "We'll design this NEW AND DIFFERENT platform in some revolutionary and awesome way, and make everyone rewrite their apps in this way feel is Better." When dealing with platforms, the one most important thing to do, in my opinion, is to HIDE the differences between one and another platform as much as possible. Android does this to some degree WITHIN the Android ecosystem, but we simply DON'T NEED multiple ecosystems. I submit it would be better for everyone if there were a single cross-platform engine that everyone used. Before I get dismissed as a kook, please think about OpenGL, and the fact that something as complex as a rendering subsystem IS in fact supported on all platforms, to everyone's benefit.
What would have been better is a library that abstracts away the fact that Android is its own unique OS, period. When I write code, I don't want it to be Android code, or iOS code, or WebOS code, or Windows [Mobile] code, or Linux code. I want it to be, as much as possible, completely cross-platform. I want the platform to fade into the background. You could bootstrap this by creating all the UI and other OS code as a portable layer that can run on many different systems.
But no new platform developer ever seems to get that, and so we end up with a new ecosystem for every new platform, and it's left to third parties to fill in the gap with cross-platform libraries. But it's not the developers -- or the users -- that big initiatives like Android get funded to satisfy.
/rant
Re: A few days of programming on iOS and Android illustrates a vast difference.
#57Earlier quoted context omitted.
This is interesting because I, having no knowledge of the Android market but a lot of knowledge of development in general, would give the exact opposite advice! In general I think it's agreed that the best thing to do is release, and then tweak. If the Android Market punishes people that do this then I think that's a very real problem with the market that will directly lead to poorer quality software.
The release and tweak model works well for web apps -- today. Because there is no real review model for web apps. Mobile apps are a lot more like movies. Opening weekend means a LOT. If you are weak out the gate, you'll have bad reviews. When you update, no one will care, because not many people will buy the updated app because of all the one-star reviews. The only time this doesn't apply is if you a huge built in us…
Re: A few days of programming on iOS and Android illustrates a vast difference.
#58Counterpoint: I just began developing my first Android app a few days ago, a turn-based strategy game. I've only had an Android device for a month or so so the platform is relatively new to me, and I didn't even know Java (although, to be fair, I knew C# fairly well a couple years ago, which is arguably the same thing plus type inference.) In a few days, with relatively few problems, I was able to build an app and I'…
Just a word of advice on Android, polish your app really well before launch. The Android Market comment system is relentless. If you don't have a smashingly nice app out of the gate, you'll probably get a couple 1-star "sucks"/"rubbish" reviews before you can finish your post-launch exhale.
Re: A few days of programming on iOS and Android illustrates a vast difference.
#59I would love to see some scripting language in Android AND iOS which is Officially supported. Something like Python,Ruby or JavaScript which will make app development much easier. Hey Google, Give us a nice scripting langauge. Pretty Please?
Re: A few days of programming on iOS and Android illustrates a vast difference.
#60Earlier quoted context omitted.
The release and tweak model works well for web apps -- today. Because there is no real review model for web apps. Mobile apps are a lot more like movies. Opening weekend means a LOT. If you are weak out the gate, you'll have bad reviews. When you update, no one will care, because not many people will buy the updated app because of all the one-star reviews. The only time this doesn't apply is if you a huge built in us…
What would you advise then for app developers - how easy is it to operate a closed beta on Android or iPhone, for example?