Live data from Hacker News

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

plus.google.com

81–90 of 97 posts

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

#81
post #80

Earlier quoted context omitted.

Although not having used Android specifically, I can easily see the UI designer being poor compared to iOS's. I still have yet to see anything as good as Interface Builder for any other platform, and I think a lot of it just boils down to the fact that when IB was designed it was actually considered to be "the right way" to make pieces of your app from the beginning, as opposed to something bolted on later. Making a…

Moreover, Interface Builder's file format is quite literally a serialized version of the class constructed at runtime, as configured in Interface Builder. What can be done in IB can also be done in code, which is more than I can say for Android's xml.

What do you mean it's more than you can say? Android's system is precisely the same. To build an Activity you set up and extend Views using the ViewGroup function 'addview'

http://developer.android.com/reference/android/view/ViewGrou...

I actually use this to inflate a series of layouts, and then to arrange them inside an existing layout dynamically.

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

#82

WTF? This guy is an idiot. I make iOS and Android applications for a living. It is ridiculous to have to create a service to make a few HTTP calls. For that, Android/Java provides various threading classes so that you can keep multi-threaded code nice and neat. With iOS, out of the box, you get NSURL and its family. You have to setup callbacks in your class and you have to keep track of your http calls per class by u…

I definitely laughed at the irony of this post.

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

#83
post #82

WTF? This guy is an idiot. I make iOS and Android applications for a living. It is ridiculous to have to create a service to make a few HTTP calls. For that, Android/Java provides various threading classes so that you can keep multi-threaded code nice and neat. With iOS, out of the box, you get NSURL and its family. You have to setup callbacks in your class and you have to keep track of your http calls per class by u…

I definitely laughed at the irony of this post.

Care to rebuke? BTW, read hackbod's comment. She's an Android engineer. This guy is flat out wrong and failed to read documentation. She puts it much nicer than I can.

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

#84
post #57

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?

For Android, the market can be avoided by just offering the .apk file (e.g. you can self-host the .apk and only share the link with a select group, or if that's not secure enough, require a unique key to unlock the app once it's loaded).

More here: http://www.google.com/search?q=android+sideload+apk

P.S. Has anyone had success developing an Android app with Google's App Inventor tool (http://appinventor.googlelabs.com/about/index.html)?

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

#85

Earlier quoted context omitted.

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…

>Thanks, but I guess I didn't get across how much I still hate Java. ;) Can't solve that.. ;) ;) >I feel it has 95% of the problems of C++, without the advantages (predictable speed, mostly). I suppose you'd have to get a little more particular in the 95% of problems angle. I have been working with Java for quite some time and TyphonRT contains necessary workarounds or API extensions enabling predictable speed. For i…

>>I feel it has 95% of the problems of C++, without the advantages (predictable speed, mostly).

>I suppose you'd have to get a little more particular in the 95% of problems angle.

Hmm...getting very much off topic here, so I want to keep this brief, but roughly speaking I'm talking about the problems of the language being very verbose and missing a lot of useful features: no duck typing (C++ at least has templates, which have their own drawbacks -- Java generics need to be Object-derived), no coroutines, and no first-class functions are three examples that come to mind. Just look at the size of programs in the "Language Benchmark Game" -- Lua's entries are tiny compared to Java. Call me lazy. ;)

In addition, in Java you HAVE to force everything into an object paradigm, whether it makes sense or not. Lua can act object-oriented if you want it to, but you can also use it in other ways that simply make more sense to the problem at hand.

>Yes it's not a complete game engine nor is Moai which you mention you have your eye on presently.

No implied criticism there. As you mention BatteryTech is also low-level. There's a place for that.

For what it's worth, Moai does come with things like physics; not sure how they bind things together, but I would have guessed that they have a very basic engine with game objects. Could be wrong.

JavaCPP looks interesting, though I'm instead just minimizing my use of Java so I can have a Windows and iPhone version trivially.

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

>Hrm? C / C++ is available on the majority of platforms... ?

Yes, but it's the API for getting events, putting up native dialogs, etc. that will be non-native everywhere. On Android more so than usual.

And actually...C/C++ isn't currently supported on Windows Mobile, at least in the public SDK, for what it's worth. Though C/C++ are supported on pretty much every platform where the company behind it isn't being stupid, yes.

No implied criticism toward your project in general, by the way. It's just not my thing, since I'm not a Java person. It does sound like you've solved a lot of the problems that people often have with Java, though, which is great.

>Regardless of what you choose though I hope you make some cool games for Android! :)

Thanks. :)

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

#86
post #80

Earlier quoted context omitted.

Moreover, Interface Builder's file format is quite literally a serialized version of the class constructed at runtime, as configured in Interface Builder. What can be done in IB can also be done in code, which is more than I can say for Android's xml.

What do you mean it's more than you can say? Android's system is precisely the same. To build an Activity you set up and extend Views using the ViewGroup function 'addview' http://developer.android.com/reference/android/view/ViewGrou... I actually use this to inflate a series of layouts, and then to arrange them inside an existing layout dynamically.

No, there are methods and settings that can be set via code that cannot be set via the XML, and vice-versa - I'm not talking about mixing them together. Yes, they are the same classes. No, they are not created and instantiated and configured in exactly the same fashion; there are occasionally differences.

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

#87

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…

I've ported some 3D games, written in C++, to both iOS and Android .. and I don't get what the problem is? If you want to use OpenGL ES - just use it. Its quite feasible to have a full C++ - based game on Android and iOS, using the same codebase, with some environment-related (OS specific) glue code to get it working on the target platform.

I got my apps ported and basic iOS/Android shells set up, and I haven't had to go back to the code for the OS-specific stuff in 6 months - all the continued development work has been in C++ at the GL ES level.

So, I would say, if you do your work properly you can set up a very comfortable environment, as a games programmer, to support cross-platform development on these platforms with ease.

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

#88
post #77
post #48

Earlier quoted context omitted.

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…

Verbose is putting it mildly. Objective C isn't a bad language, but the syntax is just horrible IMO. So much extra typing to do something simple. That said, the app I'm writing at work does a lot of stuff with strings, which you did mention specifically as a problem. Properties also drive me crazy. just a ton of extra annoyance just to declare a variable. I also prefer eclipse to xcode, and visual studio to both. oh…

What is the annoyance with declaring properties? How is it worse than other languages?

You have a single line that specifies a property and then a single line to synthesize the accessors if you don't need to do anything unique inside them.

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

#89
post #86

Earlier quoted context omitted.

What do you mean it's more than you can say? Android's system is precisely the same. To build an Activity you set up and extend Views using the ViewGroup function 'addview' http://developer.android.com/reference/android/view/ViewGrou... I actually use this to inflate a series of layouts, and then to arrange them inside an existing layout dynamically.

No, there are methods and settings that can be set via code that cannot be set via the XML, and vice-versa - I'm not talking about mixing them together. Yes, they are the same classes. No, they are not created and instantiated and configured in exactly the same fashion; there are occasionally differences.

Such as? I don't mean to carry on an endless comment thread but I don't quite understand what you're talking about.

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

#90

Earlier quoted context omitted.

My rule of thumb: - if you see "java.awt" or "javax.swing" in any package import, run away. - if you need to download a native library to run a hello world, run away too. The rest is/should be fair game. Try to run a hello world on the device.

Is there a good library for doing graphics in Java? I was thinking about trying processing, but it doesn't seem quite appropriate.

What kind of graphics? - for charts on android, http://code.google.com/p/afreechart/ - for maths calculations, http://commons.apache.org/math/ - for opengl graphics on android, it's already a pain with all the fragmentation here. There's OpenglES10 (but no longer implemented on Xoom), OpenglES20 (2.2/2.3 and up, but no VBO support on 2.2), Renderscript (3.0 and up), JNI (if you want to program in C), MonoAndroid (for mono, you need to pay for that though)... - otherwise, just go with the official Canvas API http://developer.android.com/guide/topics/graphics/index.htm...
Post reply on HN