Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A few days of programming on iOS and Android illustrates a vast difference.

plus.google.com

Post reply on HN
Print view View original

61–70 of 97 posts

Re: A few days of programming on iOS and Android illustrates a vast difference.

#61

Post by msbarnett »

ZoFreX wrote: post #57
kenjackson wrote: post #47

Earlier 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?

On iOS it is quite easy using the excellent TestFlight service: http://testflightapp.com/

Re: A few days of programming on iOS and Android illustrates a vast difference.

#63

Post by ristretto »

Wouldn't it be better though if we did not have to rely on either apple or google for mobile programming? How about extending trusty old HTML to provide low level Apis for mobile devices? Phone gap does it and it's already proving valuable. As mobile bandwidth is becoming more stable it makes more sense to quit the app store madness and embrace the wild open web as the only app platform. In principle I do not see why there isn't a set of mobile browser extensions already; i suspect that both google and apple will use their platforms as a tool to lock in developers to their own strategies.

Re: A few days of programming on iOS and Android illustrates a vast difference.

#64

Post by rudy750 »

bendmorris wrote: post #32

Counterpoint: 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 keep hearing from iOS camp that NO ONE buys android apps. What are your experiences?

Re: A few days of programming on iOS and Android illustrates a vast difference.

#65

Post by extension »

SomeCallMeTim wrote: post #56
bendmorris wrote: post #32

Counterpoint: 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'm a long-time game programmer, and not at all an Apple fan (somewhat the opposite, in fact). When I picked up Android I really, really wanted to like it. 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 be…

But no new platform developer ever seems to get that

I think everyone gets the value of cross-platform development, but in reality it's very difficult to achieve without enormous compromises and history tends to plot against it.

Apple's platform (Objective-C/Cocoa) can be traced back to NeXTstep. In 1988, it was the most progressive thing out there and some would say it still is. Apple leveraged their existing technology and ecosystem through OSX and all the way to iOS.

But the rest of the industry went in other directions. Objective-C/Cocoa would have been a strange choice for Android and would only have made it even more vulnerable to Apple's formidable patent arsenal. Instead, Android uses Java, which is also an attempt to leverage an existing ecosystem. But Android's fairly novel models of user interaction and application lifecycle required a whole new API. And Google had to reimplement the VM to avoid license fees, which still wasn't enough to avoid a patent attack.

In summary, as long as we have a) innovation and b) lawyers, we will constantly have to learn new development platforms which may not always be entirely novel.

Re: A few days of programming on iOS and Android illustrates a vast difference.

#66

Post by MichaelEGR »

SomeCallMeTim wrote: post #56
bendmorris wrote: post #32

Counterpoint: 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'm a long-time game programmer, and not at all an Apple fan (somewhat the opposite, in fact). When I picked up Android I really, really wanted to like it. 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 be…

@SomeCallMeTim >I submit it would be better for everyone if there were a single cross-platform engine that everyone used.

>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. ---

There are options out there. I'm one of those 3rd parties soon releasing a comprehensive middleware solution for app dev including a lot of game dev oriented effort that provides a clean abstraction layer via a component architecture that uses a large majority of advanced Java language features under the hood without sacrificing performance.

Keep a watch out for TyphonRT; drop me an email via the contact address and I'll be glad to discuss more and make sure you get early access. I'm aiming to get it out ASAP and before I give an all day game dev workshop at AnDevCon II in November. I suppose one thing that makes TyphonRT unique is that it's a tool, framework, and future platform (PaaS). At the heart of things you can pick and choose individual blocks of functionality (tool), or utilize the runtime framework (framework), and soon there will be optional PaaS features aiding Android and cross-platform dev in the coming year after launch.

Another Java based cross-platform effort which is similar in purpose though significantly different at the architecture level is libgdx. For C/C++ check out Battery Tech and the Proton SDK for similar cross-platform efforts (both of these with even more device coverage).

TyphonRT provides that layer of sugar you seek without losing performance and creating full cross-platform execution for OpenGL apps without changing a line of code for J2SE -> Android. TyphonRT is not limited to OpenGL though and can utilize any graphics API potentially allowing a hybrid UI, but the rest of an app still being cross-platform.

Having worked intensely with Android since v1.0 and the G1 hit my hands in Oct '08 I have more than a few stories on the difficulty of low level development / games, etc. across different OS and major device hardware generations. I've experienced first hand a good deal of general engineering blunders and have found and reported a few major ones myself (you know when big G fixes a bug immediately upon being reported you found a good one; the 3.0 & 3.1 / NIO immutable endian swap issue comes to mind!).

Middleware will mature and soon provide a lot that the Android SDK lacks for certain app development areas. In many ways the Android SDK while novel in several areas is still being developed from an old engineering model, but that is seemingly unavoidable for a large organization such as Google. There are of course additional inherent problems with tying the SDK to firmware, but such is life.

I do agree with your last point though that generally the SDK in addition to the particular ecosystem quirks that have occurred over time isn't exactly indicative of satisfying developers.

Re: A few days of programming on iOS and Android illustrates a vast difference.

#67

Post by hackbod »

"For example, to correctly implement asynchronous HTTP requests is an entirely different challenge in iOS and Android. On iOS you use the built in libraries, and if your user happens to change applications during the request, you can be sure you have up to 30 seconds, usually more, to complete whatever actions need done before termination. On android, you must implement the `android.app.Service` API for all your important web calls. The app can be killed at any time, and you must retain your arguments, and retry the call in case it happens to die."

Except... no, you don't. :/

The first sentence of the documentation on Service: "A Service is an application component representing either an application's desire to perform a longer-running operation while not interacting with the user or to supply functionality for other applications to use."

Do you need to do either of those things? If you say no, then don't use Service.

http://developer.android.com/reference/android/app/Service.h...

In the Processes and Threads documentation: http://developer.android.com/guide/topics/fundamentals/proce...

It describes how when the user leaves the activity in a process, it goes in the background. It doesn't kill the process. You can continue doing networking. You don't need a Service to have background threads in your process. (In fact again from the Service documentation, a Service is not a thread at all.)

Just continue doing your work, and if the system needs your RAM for other processes, it will kill your process, but otherwise you can continue downloading in the background.

This is exactly how for example the web browser, and any app using a WebView, works.

This is similar in many ways to iOS. Not surprising, iOS seems um inspired in its multitasking design by Android.

Re: A few days of programming on iOS and Android illustrates a vast difference.

#68

Post by anyidiot »

SomeCallMeTim wrote: post #56
bendmorris wrote: post #32

Counterpoint: 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'm a long-time game programmer, and not at all an Apple fan (somewhat the opposite, in fact). When I picked up Android I really, really wanted to like it. 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 be…

Yes, C# is way better for games because you can write mixed format display buffers, but Java isn't that bad as long as its JITed. It limits you to post 2.2 droids, but if doesn't have 2.2 on it, it probably has the shitest of graphics hardware anyway.

I dont get your other complaints though. Show me a developer guide for a console platform that doesn't have outright lies in it and I'll show you my unicorn.

There is a single cross-platform engine, btw, its called Unity, and if you can live with its constraints, then off you go.

Its not in the platform creators best interest to make it compatible with other platforms. So dont hold your breath for write-once that doesnt suck.

Re: A few days of programming on iOS and Android illustrates a vast difference.

#69

Post by SomeCallMeTim »

MichaelEGR wrote: post #66
SomeCallMeTim wrote: post #56

Earlier quoted context omitted.

I'm a long-time game programmer, and not at all an Apple fan (somewhat the opposite, in fact). When I picked up Android I really, really wanted to like it. 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 be…

@SomeCallMeTim >I submit it would be better for everyone if there were a single cross-platform engine that everyone used. >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. --- There are options out there. I'm one of those 3rd partie…

Thanks, but I guess I didn't get across how much I still hate Java. ;) I feel it has 95% of the problems of C++, without the advantages (predictable speed, mostly). I'm sure your platform will be useful for anyone porting J2SE code to Android, but that's not me. And it doesn't look like you're supporting iPhone? That's a huge chunk of the market still.

I know that middleware providers will step in to fill in the gaps, but it's just annoying to be non-native on ALL platforms. And there are already a lot of options.

http://www.batterypoweredgames.com/batterytech is one that I know that's low level, for instance -- it gives you events, OpenGL and sound on Windows, Mac, iPhone, and Android. It's pretty bare-bones, though, as far as I know.

There are also stacks that allow you to write in JavaScript [1][2], 3d engines [3][4][5], and one that I just found out about one that sounds really awesome, though I haven't used it yet called Moai [6]. Moai is Lua-based, open source, supports iPhone and Android, and has a Lua-based cloud server component, so you can write in the same language for your game and for the server side in multiplayer games.

If I haven't been clear, I think Lua IS an awesome language, especially now that LuaJIT 2.0 works on Android (and at least partly on iPhone), and so I'm strongly considering using Moai for my next game.

I actually already use Lua on the server side, though I'm using a different stack than Moai (they're on Mongrel2/Tir, and I'm using Nginx with lua-nginx).

[1] http://www.sencha.com/ [2] http://www.phonegap.com/ [3] http://www.stonetrip.com/ [4] http://unity3d.com/ [5] http://irrlicht.sourceforge.net/forum/viewtopic.php?t=37235 [6] http://getmoai.com/

Re: A few days of programming on iOS and Android illustrates a vast difference.

#70

Post by schiptsov »

This guy it seems trying to say that Android's APIs were developed by (talented) engineers for engineers (skilled programmers) on the go, while Apple just adopted mature libraries from OSX which are providing set of hight-level abstractions and APIs understandable by any mediocre coder (the way of 'easy/cool' java/php frameworks).

But one should remember that too high-level APIs and abstractions has its cost in terms of performance and bloatedness of required runtime (J2EE/Spring/Hibernate way) especially on resource-limited (lack of FPU, etc) platforms.

Post reply on HN