Live data from Hacker News

Android Development Tips For iOS Devs

stuartkhall.com

71–78 of 78 posts

Re: Android Development Tips For iOS Devs

#71

Earlier quoted context omitted.

I would argue that debugging is also infinitely easier in the Android world, since plugging a phone into USB and authorizing ADB gives you full control to see everything on the phone. You can get full logs and debug control over the hardware. You can push and pull stack traces and files to and from the device with a single, three operand command line and obtaining hardware screenshots requires only a click in IDE. An…

Uh. It's way harder to setup an android device for debugging. I just had to plug in my iphone and tap "use for development" at the prompt. I'm porting an iOS app to android right now, and android is way behind on the development side of things.

After you setup the provisioning profiles correctly, get the build schemes right, etc etc. Oh and don't forget to send Apple your tax id!

I would highly recommend using Android Studio + Gradle over Eclipse. IntelliJ is a significantly better tool for writing and refactoring code than XCode. Some of the tight integrations between XCode and the phone are superior (especially around profiling), but overall I think IntelliJ is a much stronger tool. Even something as simple as doing layout is vastly better on Android. There is no choice between 'in code or in Interface Builder'. XML + the viewer in Android Studio is the best of both worlds.

I also think Relative Layouts accomplish 99% of what auto layout accomplishes in a much friendlier manner.

Re: Android Development Tips For iOS Devs

#72
post #46

Earlier quoted context omitted.

In my experience anything that Xcode promises to just work, just doesn't but yes they have at least improved provisioning. The original point was that there are steps to go through, and creating a paid developer account is a non trivial step

There are steps to go through for android too. The original comment about deployment is false, and doesn't make any distinction about one time setup. > That's also because deploying an APK on a test device (or several devices) is way easier than deploying an IPA on an iOS device. False. > it's easy to push the APK to my phone as part of the build process, and I don't even have to plug my device in to do so. Also true…

Mucking around with provisioning profiles, schemes, and certificates is a part of iOS development that totally sucks.

Re: Android Development Tips For iOS Devs

#73

Earlier quoted context omitted.

Uh. It's way harder to setup an android device for debugging. I just had to plug in my iphone and tap "use for development" at the prompt. I'm porting an iOS app to android right now, and android is way behind on the development side of things.

After you setup the provisioning profiles correctly, get the build schemes right, etc etc. Oh and don't forget to send Apple your tax id! I would highly recommend using Android Studio + Gradle over Eclipse. IntelliJ is a significantly better tool for writing and refactoring code than XCode. Some of the tight integrations between XCode and the phone are superior (especially around profiling), but overall I think Intel…

I didn't have to do any of that. Xcode creates provisioning profiles for you, and appcode created the schemes I needed. I think Xcode does a decent job as well.

And you only need a tax ID if you're trying to imminently release a paid application or an app with IAP. But we're discussing development, not release.

Re: Android Development Tips For iOS Devs

#74

Earlier quoted context omitted.

Uh. It's way harder to setup an android device for debugging. I just had to plug in my iphone and tap "use for development" at the prompt. I'm porting an iOS app to android right now, and android is way behind on the development side of things.

Okay. I guess I mostly used iOS with the simulator and have less experience with their hardware interface. I just found the feature set for ADB to be pretty dang impressive. Most developers never touch even 10% of the the features even though some are very useful. I'd love to see a side-by-side comparison if someone has a link. On the other hand, having iOS connect easily to a debugger disproves nothing I said.

"Obtaining hardware screenshots is just a click in the IDE"

I shouldn't need a computer attached to get screenshots for my app. Power + home button, or cmd+S in the simulator.

Even my users can easily send me screenshots, some of the time unprompted even.

Re: Android Development Tips For iOS Devs

#75
post #46

Earlier quoted context omitted.

There are steps to go through for android too. The original comment about deployment is false, and doesn't make any distinction about one time setup. > That's also because deploying an APK on a test device (or several devices) is way easier than deploying an IPA on an iOS device. False. > it's easy to push the APK to my phone as part of the build process, and I don't even have to plug my device in to do so. Also true…

Mucking around with provisioning profiles, schemes, and certificates is a part of iOS development that totally sucks.

True but has nothing to do with what was claimed.

Re: Android Development Tips For iOS Devs

#76
post #3

"I used to think the iOS simulator was painful, now I realise it's pretty awesome. Skip the Android simulator all together and deploy to a real device, or be prepared to spend a lot of time waiting." With its "native" emulator, yes, but there are better alternatives like Genymotion. Giving up on them is not good development advice.

The android emulators not only are bitterly slow to launch and use, but they do not reflect actual device performance, unlike the iOS simulator. This makes automated testing impossible on the simulator, whereas in iOS I can run my full test suite (400-something tests) in the simulator in a couple seconds.

I find the simulator a bit deceptively fast, compared to a low spec iPhone (e.g. iPhone 4).

Also, there's the case sensitivity - iPhone Simulator is not case sensitive (maybe depends on your filesystem settings), while the device is case sensitive. This can be really annoying the first time round.

Re: Android Development Tips For iOS Devs

#77

Earlier quoted context omitted.

For the OS. Imagine 999 rows containing one line of text and the last one containing a long text spanning maybe 30 lines. To calculate the scroll accurately you need to calculate the height of 1000 elements to get the full height. Instead in the common scenario you just calculate the height of the rows displayed on the screen and estimate the height using the average and the count.

Okay, sounds like you're assuming a scenario where you need to actually create the view to figure out the height, sure. In other scenarios (contact list, list of artists and albums and songs) you know the height of an item from its type, and you can just return (one of a set of) constants like I said. That shouldn't be expensive at all.

The height is calculated automatically for the rows that are visible and you can fix it to a certain amount.

So, as screigh said, you won't have the wormy effect on contact list, artists, songs, etc. because each row is always x pixels. The same happens if you have for example a series of thin and thick rows because they average out.

Another reason why using a set of constants is not common is that we have different screen sizes and different resolutions to deal with, so what looks like a good value for a resolution might not be the best for another.

Re: Android Development Tips For iOS Devs

#78

I recently went in the opposite direction (Android -> iOS). Forget all of the flame wars. If you know one, dabbling in the other is a great learning experience. The two platforms are running roughly the same hardware and facing roughly the same challenges, and the software architects at Google & Apple have chosen different ways to solve the problems. Sometimes the patterns feel similar. You can rig up an iOS tablevie…

I agree. I just started learning Android development about a month ago with Xamarin C#. Although its in C#, as a .net developer there are so many other things to learn.

Its exciting really. You see similarities and you also see differences. I think this helps more than it hurts since these "new ideas" will help me with the other environment (and vice versa).

This actually got me interested in learning other languages/frameworks (php, haskell, ruby on rails). After I get the hang of Android, I want to play around with an iOS app from scratch. Sure, I could use some conversion software to do this job. But, I'd rather not. I like to understand what's going on under the hood. I guess its the CompSci in me.

I guess what I'm saying is that I think it is so much better to have a universal understanding of these technologies then to blindly stick to one "team".

As an aside...didn't Facebook mentioned they used PHP not because it was "better" but because it happened to be the technology that worked for what they were doing at that time?

Post reply on HN