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

Android Development Tips For iOS Devs

stuartkhall.com

Post reply on HN
Print view View original

61–70 of 78 posts

Re: Android Development Tips For iOS Devs

#61

Post by mncolinlee »

stefan_kendall3 wrote: post #55
mncolinlee wrote: post #30

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.

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.

Re: Android Development Tips For iOS Devs

#63

Post by BitMastro »

nsmnsf wrote: post #54
BitMastro wrote: post #52

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.

I don't have to imagine this, though, I've done it on iOS. It works fine, because you're rarely working with 1000 items at once. With pagination, you cache the old results, and only calculate the new 50 or so rows at a time.

On the other end, pagination is rarely used on Android, and calculating the height of a single row can be more expensive since it has to layout the children hierarchy for a row according to the screen dimensions.

Re: Android Development Tips For iOS Devs

#65

Post by nsmnsf »

BitMastro wrote: post #63
nsmnsf wrote: post #54

Earlier quoted context omitted.

I don't have to imagine this, though, I've done it on iOS. It works fine, because you're rarely working with 1000 items at once. With pagination, you cache the old results, and only calculate the new 50 or so rows at a time.

On the other end, pagination is rarely used on Android, and calculating the height of a single row can be more expensive since it has to layout the children hierarchy for a row according to the screen dimensions.

This type of layout is generally limited to social feeds, where pagination is pretty much mandatory (you have to request more results from an API). Anything entirely client-side typically uses fixed height rows.

Re: Android Development Tips For iOS Devs

#66

Post by pjmlp »

stefan_kendall3 wrote: post #60
stefan_kendall3 wrote: post #57

If you're commenting on the ease or difficulty of building iOS/Android native apps in this thread, and you aren't actively building an app for both or have built one before, you probably don't know what you're talking about. The eco-system for building and deploying apps on both sides has gotten way better in the past couple years. There are pros and cons to both sides of development.

iOS pros: Blazing fast simulator, ability to run tests through xctool or Xcode. Autolayout is extremely powerful, and you don't need to write state suspend/restore code for landscape rotation. If you're writing a new app, you can probably exclusively target iOS7. iOS cons: The device limit. This makes deploying apps to your users more difficult than it should be. Xcode is also an extremely weak IDE, but AppCode makes…

> Android cons: Emulator is for all purposes unusable.

At least on Windows it is quite usable for OpenGL ES emulation, when using Intel's virtualization driver.

Re: Android Development Tips For iOS Devs

#67

Post by rizwan »

UIViewControllers fall somewhere between an Activity and a Fragment.

In particular if you use any kind of view controller containment (custom container view controllers), you can only do that with fragments, and only then with Android 4.0+.

As someone who's looked at building tablet apps, the containment is a good thing to consider. In these cases, iOS makes it easier to combine your existing view controller hierarchies, while there are some idiosyncrasies (only 1 action bar across the top of a "split view controller") on Android still that don't always make things easy (in my opinion).

Re: Android Development Tips For iOS Devs

#68

Post by BitMastro »

nsmnsf wrote: post #65
BitMastro wrote: post #63

Earlier quoted context omitted.

On the other end, pagination is rarely used on Android, and calculating the height of a single row can be more expensive since it has to layout the children hierarchy for a row according to the screen dimensions.

This type of layout is generally limited to social feeds, where pagination is pretty much mandatory (you have to request more results from an API). Anything entirely client-side typically uses fixed height rows.

I see your point, but this layout is used also for variable height images, variable lenght text, compound layouts, etc. The equivalent of pagination on Android is usually done using pull to refresh (horizontal swipe gestures are usually used to change topics more or less).

For something completely client side it is possible either to specify a fixed height or change the smoothScrollbar attribute of the listview (it is more expensive though and not used very much).

Nobody complains, I guess everyone is just used to the way it is. :D

Re: Android Development Tips For iOS Devs

#69

Post by xsmasher »

BitMastro wrote: post #52
xsmasher wrote: post #48

Earlier quoted context omitted.

> It's very computationally heavy to ask for the heights of each ListView item. Can you expand on that? Do you mean that it's expensive for the OS for some reason, or do you mean that it's expensive for your (client) code to compute the height of each item? It seems like in most cases it's a simple method like "return isHeader : HEADER_HEIGHT : ITEM_HEIGHT;"

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.

Re: Android Development Tips For iOS Devs

#70

Post by bookwormAT »

V-2 wrote: post #4

"A trick often used by iOS devs is to use the tag of a view to hold lookup information, such as offset in arrays. With Android you can shove the entire object into the tag; pretty useful." Yes, but if it's something like a ListView, don't put offset in array there, because the views are recycled (when user scrols), so you're likely to end up with corrupted data. I got bitten by this in the beginning. You can go to gr…

If you use ViewHolder, consider using custom views instead:

http://blog.xebia.com/2013/07/22/viewholder-considered-harmf...

I refactored all my code after reading this, and now I consider the ViewHolder an antipattern.

It is incredible how much cleaner and readable my codebase is with custom views. And the performance is the same.

Post reply on HN