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

Ask HN: What do you regret you didn't know when programming for iOS or Android?

news.ycombinator.com

Post reply on HN
Print view View original

121–130 of 166 posts

Re: Ask HN: What do you regret you didn't know when programming for iOS or Android?

#121

Post by fctorial »

pcr910303 wrote: post #26
ddxxdd wrote: post #3

I regret not knowing about cross-platform development such as Flutter and ReactOS. I also regret not buying a book explaining all the concepts in as simple a manner as possible. As a semi-amateur programmer, I feel like most of the documentation is meant to refresh the memories of people who have been developing apps for years; they're extremely beginner-hostile.

> I feel like most of the documentation is meant to refresh the memories of people who have been developing apps for years; they're extremely beginner-hostile. Yeah, really agree with that; I'm not sure about the state of Google, but the word 'beginner-hostile' is really an exact state of Apple's documentation (well I'm touching AppKit not UIKit, so that's a factor too but...). Coming from a web background, almost ev…

Can you give an example of beginner hostile documentation?

Re: Ask HN: What do you regret you didn't know when programming for iOS or Android?

#122

Post by rwallace »

zmj wrote: post #101
davnicwil wrote: post #99

Earlier quoted context omitted.

> Very few companies have ever failed because their tech stack didn't scale well Just out of interest, are there any clear examples where this happened, ever? Can anyone name any? What I mean specifically is - a company with a well known product that was growing in popularity but then hit a ceiling because of technical scale issues and couldn't support any more customers, growth halted, and they couldn't fix it in ti…

It happens all the time. When it does, though, the narrative is usually "scrappy upstart takes over" and not "segment leader fossilizes".

So what would be some examples of when a scrappy upstart took over because the segment leader ran into tech stack scaling issues? (As opposed to the segment leader running into corrupt or incompetent management, failing to notice a new market opportunity etc.)

Re: Ask HN: What do you regret you didn't know when programming for iOS or Android?

#123

Post by Groxx »

The thing that would've saved me the most time and frustration in the long run for all mobile development (well, all dev period, but mobile especially as they tend to be moving targets):

Ignore the framework. Write your app how you want to write it, then attach it to the framework as needed. Don't restrict yourself to what the framework supplies or how it thinks about things.

It'll dramatically decrease craziness in your core logic in the long run. Framework versions and bugs can lead to strange lifecycle callbacks, weird interactions between the N flavors of how to build UI components, etc, and if your core logic is chopped up to deal with all of this it can become very hard to make important changes. Such as updating to a newer version of the framework so your app isn't removed from the stores.

It'll pretty much always be more up-front code and work, but you'll be left with a far clearer system in the end.

Re: Ask HN: What do you regret you didn't know when programming for iOS or Android?

#125

Post by balladeer »

I wish I had realised that Android app development ecosystem (the dev tools, API, documentation, gradle, dependency management etc) is a shit show and is going to remain a shit show and I should have moved to backend early in my career. Now companies are very reluctant about it.

Re: Ask HN: What do you regret you didn't know when programming for iOS or Android?

#126

Post by rmdashrfstar »

Groxx wrote: post #123

The thing that would've saved me the most time and frustration in the long run for all mobile development (well, all dev period, but mobile especially as they tend to be moving targets): Ignore the framework. Write your app how you want to write it, then attach it to the framework as needed. Don't restrict yourself to what the framework supplies or how it thinks about things. It'll dramatically decrease craziness in…

Related to this is “clean architecture”. Your code should not be dependent on a feature-laden framework. You should focus on writing your business domain and rules, then separately orchestrate your domain, and connect the UI and other external frameworks as interfaces to the lower, or more generic, levels of your application.

This is a general software design principle that allows for your UI to be free to change without affecting your core logic and rules, while also making all of your code more unit testable.

Re: Ask HN: What do you regret you didn't know when programming for iOS or Android?

#128

Post by mettamage »

I should've started a year later when ARC was introduced (I started learning between 2011 - 2013).

Learning iOS dev with reference counting as a memory management system was really painful. My programming skill wasn't up to speed yet to "just" learn a new language. I only knew some university Java at the time. And while I did write impressive projects with it, I wasn't strong enough in an algorithmic sense.

Learning a framework and learning memory management, and kind of needing to deal with pointers but not really proved to be too much.

When ARC was introduced it was a breeze.

Now, when I read this whole comment, nowadays I'd think: this is such nonsense. Memory management should not be a barrier to learn iOS dev. But when you're in that weird space of that you kind of know how to program (5000+ lines code) but you really need to get into it, and it doesn't feel natural yet. Then, yea, it does matter a lot.

A few years later I learned C and had no issues learning pointers or memory management. To be fair, I didn't need to use any frameworks with C.

Re: Ask HN: What do you regret you didn't know when programming for iOS or Android?

#129

Post by habosa »

Been doing Android development for 8+ years. The main thing to realize is that nobody actually knows what they're doing. You'll have a problem and spend hours and hours just searching for "the answer" but it's not out there. Everyone who has solved it has used their own hacks, and they're not going to be able to transfer the hack to you.

Once you realize this it's somewhat liberating. You focus on the bug/feature and not the method. One time I was trying to solve a particularly nasty layout-at-runtime problem and just realized I could write my own ViewGroup and lay it all out myself, pixel by pixel, faster than fighting RelativeLayout or whatever. And that code is more stable than something where I import some library that's not going to be maintained.

Post reply on HN