21–30 of 166 posts
Work = looks and feels native, good performance, good widget collection, development that doesn't fight the platform, and all those available not 10 years after the platform was introduced.
Image loading was often a huge source of crashes due to out-of-memory errors and doing it properly wasn't trivial [0]. Libraries like "Glide" and "Picasso" solved this.
Using the camera hardware was awful. Device manufacturers would implement things differently, and break the camera API unexpectedly. Only recently [1] are we starting to see sane, consistent camera APIs.
Making network requests felt extremely clunky, and the platform JSON implementation wasn't performant, or easy to use as you had to manually parse everything. Retrofit [2] made talking to REST services much easier.
I could go on and on, but I'm sure there's plenty others here who can do that here. These days Android development is much, much more enjoyable. Kotlin has pretty much replaced Java in the Android ecosystem, and there's great reasources around on how to architect your app to make everything testable and easily scalable such as the architecture samples [3]. I've worked on a few React Native projects in the last year. I'm not a fan of it, but I definitely see the industry heading to some cross platform solution eventually.
[0]. https://developer.android.com/topic/performance/graphics/loa...
[1]. https://developer.android.com/training/camerax
I should’ve known that it’s turtles all the way down. Considering how many years I’ve sunk into programming for other platforms, this shouldn’t have come as a surprise, but I got suckered into believing that mobile computing platforms represented a significant enough paradigm shift to allow for starting with a cleaner slate. Not true! Having gotten into iOS development over the past couple of years, I’ve come to real…
I consider this a feature: the older code has known behaviour, while a from-scratch implementation would have been a minefield of unknown bugs
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.
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 every web framework had a starting point from the documentation or at least some concept documents: Apple's documentation is almost non-existent. The best documentation I could find was the archived ones from early 2010s, and those were not really helpful at all.
I did know Apple's dev experience isn't really great... but what I did not know was that learning Apple's APIs/conventions means watching three and four WWDC videos that briefly touch the API for about two or three minutes, learning two languages together(Swift & Objective-C -- which actually wasn't really that awful for me b.c. I already knew much about ObjC & message passing due to my interest in various (elegant) PLs), & searching for other people's personal projects from GitHub.
Seriously Apple, improve your documentation. It's just plain awful.
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.
React? ReactOS is the open source version of Windows NT
That JavaScript (and prior to that, Java) would work for mobile, one platform to rule them all. Work = looks and feels native, good performance, good widget collection, development that doesn't fight the platform, and all those available not 10 years after the platform was introduced.
It has been a nightmare of keeping up with the majors, just to be able to enter their carefully curated arena.
Nowadays when I build an App, I do Linux/Mac/Windows first, and the iOS/Android release, next. Fortunately there is a vast industry out there for toolkits and frameworks for solving The Platform Problem™ which has been shoved down our throats by a ravenous corporate culture which is hell-bent on ensuring that they own the computing platforms of the future.
Ditto async and observer and livedata type stuff. Never move data between things any way other than async. MVVM and all that, with caching repositories and stuff.
Architecture changes fast enough that you have to be careful not to waste time and effort supporting some ancient version and NIH writing your own implementations of stuff that's newly added in current versions. Yet if you try to ship using cool alpha quality features, that's a whole different headache. For extra fun you can end up with both problems at the same time in different parts of the app.