I'm a self taught programmer and started developing for Android in 2012. It took me a while before I realised that you needed third party libraries to do absolutely anything useful as the platform APIs were so poor and undocumented. There were gaps everywhere and you needed to write tons of boilerplate code to do things properly.
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.
Personally I think that Flutter is the future for cross-platform UI toolkits. As a React dev (in my spare time, I’m still a student), using RN was a pain due to the need to install native extensions for almost everything. The batteries-included approach of Flutter and just the polish around the dev workflow made it more attractive to a beginner mobile dev.
>Even Google's own Pixel devices do not support this. The image quality from CameraX API is not ass good as the stock camera. And there is no support for Night Sight. I do not get this.
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 realize that seemingly no attempt has been made to actually clear the cobwebs on this shiny, relatively new platform.
For example, SwiftUI is just an abstraction layer for UIKit, which itself is (keep me honest, HN) an abstraction for some mishmash of Cocoa, Display PostScript and Metal. Bits of NeXTSTEP are everywhere still, even when using Apple’s latest and greatest programming paradigms.
Don’t get me wrong, iOS is great, and I love it to death. However, the baggage signals to me that a massive opportunity to start anew has been missed.
> Don’t get me wrong, iOS is great, and I love it to death. However, the baggage signals to me that a massive opportunity to start anew has been missed.
Starting anew is over rated. It’s sometimes the right answer, sure, but it’s just one possible answer. iOS benefited enormously from being immediately familiar and approachable to existing OSX devs, and would have taken another 5+ years to develop from scratch without leveraging its OSX heritage.
Meanwhile Android was in a crash emergency race to relevance for the first 5 years of its existence. If they’d taken the time to do everything right the first time, they could have ceded Microsoft enough time to get their Windows Mobile act in gear.
So legacy is a thing for a reason, taking one opportunity very often means giving up another.
I think certain paradigms were completely shifted compared to the PC space.
-Revamped permissions
-App packaging/name spacing/consistent installation
-IPC was redesigned as asynchronous Intent blobs on Android
-Urls becoming first class citizens at the OS level
-More consistent background app apis (and eventually better ways to track them)
I could come up with more but I think there's actually a very big difference. But yes, its all built on top of older Java and obj-c libs.
SwiftUI isn’t UIKit-specific. Display Postscript hasn’t existed since the OS was called NeXT, 20+ years ago, and was never on any iDevice. Cocoa is an alias for AppKit + CoreData, and iOS uses CocoaTouch instead.
> Don’t get me wrong, iOS is great, and I love it to death. However, the baggage signals to me that a massive opportunity to start anew has been missed.
I guess that's what Flutter is doing (for both iOS and Android).
A lot of people are recommending using cross platform solutions. As a hobby or learning exercise, go for it! As someone who has a career across many projects working full time as a native iOS and Android dev, I can say these solutions are generally avoided. They are good for prototypes you don’t plan to maintain long term, I’ll give them that.
I know it’s cheesy but my only regret is I didn’t go all-in on mobile sooner. I have been on a constant upward career trajectory since the day I put my first app on the store. Get an app on the store as soon as you can and if it gets traction listen to feedback and update it. If you’re early in your career this will be the only thing on your resume that matters. I highly recommend you start with iOS just because the tools are more friendly for beginners. Watch WWDC/Google IO sessions and keep up with the latest. However it’s best to keep a healthy distance with things that only support the newest OS. For instance I wouldn’t build an app in SwiftUI yet but I follow it like a hawk because it’s likely to be the only way Apple platform apps are made very soon. Closely follow VR/AR frameworks and machine learning. Those will become must-know this decade.
Mobile dev is so rewarding! Every developer should at least dip their toes in.
That developing for Android isn’t even as half as smooth as developing for iOS. Yes, with iOS you’re using Xcode and have to set up provisioning for your dev device and all that, but once you’ve done that you’re mostly on your way. UIKit, while not the shiniest thing out there, is quite competent and functional — you can easily write world class apps with it while keeping third party libraries to a minimum.
On Android, setting up for development is a bit faster but the actual development story is so, so much worse. Kotlin improved things a great deal and Jetpack improves it further, but it still has such a long way to go. You’ll spend inordinate amounts of time researching the “right” way to do things only to find that there really isn’t one, but instead several ways with varying levels of wrongness with different trade offs. Even mundane things will be a source of trouble and you will likely have to make concessions in your UI design to work around Android SDK awkwardness.
If I could just have UIKit on Android I would be a much, much happier Android dev. Hoping Jetpack Compose improves the situation but I’m not holding my breath.
> You’ll spend inordinate amounts of time researching the “right” way to do things only to find that there really isn’t one, but instead several ways with varying levels of wrongness with different trade offs.
From what I've heard Android is unusually bad for this but this particular sentence resonates with me in terms of basically everything ... though that may be because I do a bunch of deployment/ops stuff which is generally entirely made out of "choose your own petard to be hoist by later"
I started Android programming from the command line using make/ant and testing on a device because I didn't like Android Studio. This ended up wasting a lot of time and energy over the years as I had to integrate more 3rd party libraries (including Google's own crap).
Same thing for iOS. I didn't like building GUIs in Interface Builder so I did everything in code. Over time as iOS devices came in different sizes, this became harder to do properly. I should have given in early and learned to use Interface Builder, auto layout, etc.
I've been doing iOS for a while and I also fought AutoLayout for too long. I found doing it in code better than trying to get IB right, especially when working on a team.
Code-only purists are still prominent in the iOS community. Yeah, there’s definitely baggage one must take on when using IB but the ease of being able to instantly preview your layout in different sizes is the big seller for me.
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.
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.
With React hooks or android component life cycle its hard separate the framework and logic. How do you do it ? Any recommended books or other resources ?
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 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.
Agreed. This absolutely kills me when people say “just read the documentation” or “the documentation is very good” as a reason why they don’t produce examples or templates or starter kits. Not all of us are CS majors or programmers in large teams or with decades of experience to fall back on. Just reading the documentation isn’t enough to get me into a new framework or language. I need to see practical examples.
For mobile development, this is why Expo was so crucial for me to understand how React Native works.
The problem isn't that they're providing documentation which is good but only appropriate for a narrow audience. The documentation is just bad: it misses out things that need to be said.
To be fair, most cross-platform projects have been total garbage (PhoneGap, Titanium, etc.) Sadly the only one decent was .. Unity, which is why you'll sometimes see things that aren't even games written in it for mobile.
I worked on a react native project a year ago and hated it, mostly because of the story regarding interop with native code or SDKs. I imagine my experience would have been a lot better if the team didn’t “eject” from create-react-app-native, but I’m not sure how feasible it is to develop an app with ejecting.
On Android, that there hasn't been much love for C/C++ and the NDK is full of interesting pitfalls:
Oh your camera gives you NV21 frames, but the hardware VP8 encoder only accepts I420? Makes perfect sense.
Oh, we don't actually let you query what format the encoder expects until a later API than you're using. Just try them in a loop until one doesn't fail, makes perfect sense.
The camera was a party too, added a listener for Camera session events and the app crashed. Yay.
The Android camera issues you reference reached all the way up to the higher level Java APIs, at least back when I was doing Android development from 2012 until about a year ago. Dunno if it has gotten any better since then.
All of the MediaCodec APIs were quite powerful, but did nothing to "keep the easy things easy" or hide much of the lower level hardware details from your app.
This is kind of a theme in Android (or was... my experience is slightly out of date right now).
As mentioned by "McDev" in what is currently the top post on this thread it is a good idea to use time-tested third party libraries to do things that you'd kinda expect the OS to handle naively because the OS level APIs don't do a great job at abstracting any of the details away even for things that you'd think you shouldn't have to worry about, like basic image loading with caching and resizing. And that's just still images, never mind when you get into video de/compression.
Hopefully this is something the Android team is working on as they shift more effort toward Kotlin and Jetpack but I haven't had enough recent hands-on experience to know if this is better now.
If you built it, they wont come. Without marketing, the odds of your customers discovering the app (amongst a sea of garbage) are insanely low. I tried a Tennis app in 2009 and even back then it was competing with hundreds of other apps, now its mist likely 10’s of thousands. Heart breaking.
The years it took to realize how under-resourced the NDK team is, bothering to create my own NDK wrappers to work around the NDK bindings and forced JNI calls, manually dealing with dependencies across NDK projects.
In retrospect, it would have been easier to just rewrite the whole thing in Android Java.
Basically, how little Google cares for game related development workflows on Android.
It just took them 10 years to acknowledge this, go figure.
Don’t underestimate the value of build tools. Just because you know Xcode and Swift or Android Studio and Kotlin (or their antecedent languages) are you done. Finally having a senior dev who knows what he’s talking about has done more for me in the past two years than the previous 8 of reading blog posts and hacking. He’s shown me the real value of build scripts. Today even my personal iOS projects are dependent on a combination of Swift, Ruby, YAML, and Kotlin to build. It’s complicated to set up but I can prove that my code works.
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.
I regret it took me 5 years of mobile development (both platforms) to realize I really don’t like writing GUI code. I switched to backend and infrastructure work and I’ve been a lot happier since.
Example code is invariably dross from an architectural point of view.
Unit tests are still valuable in a mobile environment.
Most good apps are simple. Simplicity is not easy.
Some aspects of mobile development will become far easier over time (memory management on iOS) while some will remain in a baffling stasis (refactoring tools in Xcode). It’s impossible to predict which category an aspect belongs to ahead of time.
There are times to embrace the approach taken by a platform, and times to distance yourself from it.
Mobile as a platform will crush all before it and transform society, while most contemporary technological hopes will remain geek toys.
The remembering self can really help out the experiencing self; you can never learn too much about the past, present, and future of mobile programming.
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.
For android, get good at handling null everywhere in everything checking all the time now, or learn it the hard way later. You'll be spending lots of time tracking down "wait, how could that have ever possibly returned a null?"
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.
I got pretty good at Android development and made a few apps that don't have many downloads but I'm still proud of and wanted to share with my friends and family.
I regret that all of my friends and family have iPhones.
I develop for Android since 2011. Since 2016 I also do more iOS. I mostly regret not looking into new developments faster. Things like Kotlin and Architecture Components. They are great, so at least experiment a bit with them to see what all the fuzz is about. Try to keep up!
Also, I wish I realized that Google Play is giving you a lot of stats and data about your apps (store) performance these days, which in most cases can help pinpoint a issue with your reach/growth.
Amen. Management at a company I worked as were convinced that Xamarin was One True Path for mobile development. They were sold the idea that a Windows dev could instantly be productive in Xamarin without needing to understand the underlying platforms significantly.
To be clear, I do think Xamarin remains an interesting idea, but it's absolutely not the first thing I'd reach for when starting a x-platform mobile project.
[+] [-] McDev|6 years ago|reply
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
[2]. https://square.github.io/retrofit/
[3]. https://github.com/android/architecture-samples
[+] [-] applecrazy|6 years ago|reply
[+] [-] rofrol|6 years ago|reply
From the comment 2 months ago https://www.youtube.com/watch?v=QYkTXJ2TuiA&lc=UgwBlx_R3eL4k...
[+] [-] maxaf|6 years ago|reply
Not true! Having gotten into iOS development over the past couple of years, I’ve come to realize that seemingly no attempt has been made to actually clear the cobwebs on this shiny, relatively new platform.
For example, SwiftUI is just an abstraction layer for UIKit, which itself is (keep me honest, HN) an abstraction for some mishmash of Cocoa, Display PostScript and Metal. Bits of NeXTSTEP are everywhere still, even when using Apple’s latest and greatest programming paradigms.
Don’t get me wrong, iOS is great, and I love it to death. However, the baggage signals to me that a massive opportunity to start anew has been missed.
[+] [-] simonh|6 years ago|reply
Starting anew is over rated. It’s sometimes the right answer, sure, but it’s just one possible answer. iOS benefited enormously from being immediately familiar and approachable to existing OSX devs, and would have taken another 5+ years to develop from scratch without leveraging its OSX heritage.
Meanwhile Android was in a crash emergency race to relevance for the first 5 years of its existence. If they’d taken the time to do everything right the first time, they could have ceded Microsoft enough time to get their Windows Mobile act in gear.
So legacy is a thing for a reason, taking one opportunity very often means giving up another.
[+] [-] jayd16|6 years ago|reply
[+] [-] ken|6 years ago|reply
[+] [-] erokar|6 years ago|reply
I guess that's what Flutter is doing (for both iOS and Android).
[+] [-] gumby|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] mobiledev2014|6 years ago|reply
A lot of people are recommending using cross platform solutions. As a hobby or learning exercise, go for it! As someone who has a career across many projects working full time as a native iOS and Android dev, I can say these solutions are generally avoided. They are good for prototypes you don’t plan to maintain long term, I’ll give them that.
I know it’s cheesy but my only regret is I didn’t go all-in on mobile sooner. I have been on a constant upward career trajectory since the day I put my first app on the store. Get an app on the store as soon as you can and if it gets traction listen to feedback and update it. If you’re early in your career this will be the only thing on your resume that matters. I highly recommend you start with iOS just because the tools are more friendly for beginners. Watch WWDC/Google IO sessions and keep up with the latest. However it’s best to keep a healthy distance with things that only support the newest OS. For instance I wouldn’t build an app in SwiftUI yet but I follow it like a hawk because it’s likely to be the only way Apple platform apps are made very soon. Closely follow VR/AR frameworks and machine learning. Those will become must-know this decade.
Mobile dev is so rewarding! Every developer should at least dip their toes in.
[+] [-] MarvelousWololo|6 years ago|reply
[+] [-] kitsunesoba|6 years ago|reply
On Android, setting up for development is a bit faster but the actual development story is so, so much worse. Kotlin improved things a great deal and Jetpack improves it further, but it still has such a long way to go. You’ll spend inordinate amounts of time researching the “right” way to do things only to find that there really isn’t one, but instead several ways with varying levels of wrongness with different trade offs. Even mundane things will be a source of trouble and you will likely have to make concessions in your UI design to work around Android SDK awkwardness.
If I could just have UIKit on Android I would be a much, much happier Android dev. Hoping Jetpack Compose improves the situation but I’m not holding my breath.
[+] [-] mst|6 years ago|reply
From what I've heard Android is unusually bad for this but this particular sentence resonates with me in terms of basically everything ... though that may be because I do a bunch of deployment/ops stuff which is generally entirely made out of "choose your own petard to be hoist by later"
[+] [-] aquabeagle|6 years ago|reply
I started Android programming from the command line using make/ant and testing on a device because I didn't like Android Studio. This ended up wasting a lot of time and energy over the years as I had to integrate more 3rd party libraries (including Google's own crap).
Same thing for iOS. I didn't like building GUIs in Interface Builder so I did everything in code. Over time as iOS devices came in different sizes, this became harder to do properly. I should have given in early and learned to use Interface Builder, auto layout, etc.
[+] [-] cschep|6 years ago|reply
[+] [-] vlozko|6 years ago|reply
[+] [-] Groxx|6 years ago|reply
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.
[+] [-] rmdashrfstar|6 years ago|reply
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.
[+] [-] richard78459|6 years ago|reply
[+] [-] ddxxdd|6 years ago|reply
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.
[+] [-] pcr910303|6 years ago|reply
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.
[+] [-] freehunter|6 years ago|reply
For mobile development, this is why Expo was so crucial for me to understand how React Native works.
[+] [-] mjw1007|6 years ago|reply
The problem isn't that they're providing documentation which is good but only appropriate for a narrow audience. The documentation is just bad: it misses out things that need to be said.
[+] [-] mattl|6 years ago|reply
[+] [-] djsumdog|6 years ago|reply
[+] [-] self_awareness|6 years ago|reply
Then I regret looking into Nativescript, because it was pretty buggy.
Then I regret not knowing about Flutter earlier.
THEN I regret not knowing that Flutter is pretty buggy as well.
Next step is me trying to learn other frameworks, like Cordova or React Native. I wonder what my regrets will be.
[+] [-] stevewodil|6 years ago|reply
The one PITA for me is state management, but once you understand how to solve that using BLoC or Providers then it should be relatively usable
[+] [-] darksaints|6 years ago|reply
[+] [-] JoeyJoJoJr|6 years ago|reply
[+] [-] sansnomme|6 years ago|reply
https://github.com/nolanlawson/pinafore
Runs better than most native apps.
[+] [-] pjmlp|6 years ago|reply
All software has bugs, and the less amount of layers to debug the better.
[+] [-] allo37|6 years ago|reply
Oh your camera gives you NV21 frames, but the hardware VP8 encoder only accepts I420? Makes perfect sense.
Oh, we don't actually let you query what format the encoder expects until a later API than you're using. Just try them in a loop until one doesn't fail, makes perfect sense.
The camera was a party too, added a listener for Camera session events and the app crashed. Yay.
[+] [-] georgemcbay|6 years ago|reply
All of the MediaCodec APIs were quite powerful, but did nothing to "keep the easy things easy" or hide much of the lower level hardware details from your app.
This is kind of a theme in Android (or was... my experience is slightly out of date right now).
As mentioned by "McDev" in what is currently the top post on this thread it is a good idea to use time-tested third party libraries to do things that you'd kinda expect the OS to handle naively because the OS level APIs don't do a great job at abstracting any of the details away even for things that you'd think you shouldn't have to worry about, like basic image loading with caching and resizing. And that's just still images, never mind when you get into video de/compression.
Hopefully this is something the Android team is working on as they shift more effort toward Kotlin and Jetpack but I haven't had enough recent hands-on experience to know if this is better now.
[+] [-] smallstepforman|6 years ago|reply
[+] [-] pjmlp|6 years ago|reply
In retrospect, it would have been easier to just rewrite the whole thing in Android Java.
Basically, how little Google cares for game related development workflows on Android.
It just took them 10 years to acknowledge this, go figure.
https://android-developers.googleblog.com/2019/12/android-ga...
[+] [-] dfansteel|6 years ago|reply
[+] [-] ronsor|6 years ago|reply
Can you elaborate on this? It just sounds like you have unnecessary complexity.
[+] [-] ismail-khan|6 years ago|reply
[+] [-] Lich|6 years ago|reply
[+] [-] habosa|6 years ago|reply
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.
[+] [-] vbsteven|6 years ago|reply
[+] [-] hyko|6 years ago|reply
Unit tests are still valuable in a mobile environment.
Most good apps are simple. Simplicity is not easy.
Some aspects of mobile development will become far easier over time (memory management on iOS) while some will remain in a baffling stasis (refactoring tools in Xcode). It’s impossible to predict which category an aspect belongs to ahead of time.
There are times to embrace the approach taken by a platform, and times to distance yourself from it.
Mobile as a platform will crush all before it and transform society, while most contemporary technological hopes will remain geek toys.
The remembering self can really help out the experiencing self; you can never learn too much about the past, present, and future of mobile programming.
[+] [-] wiradikusuma|6 years ago|reply
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.
[+] [-] VLM|6 years ago|reply
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.
[+] [-] idrios|6 years ago|reply
I regret that all of my friends and family have iPhones.
[+] [-] peterdekr|6 years ago|reply
Also, I wish I realized that Google Play is giving you a lot of stats and data about your apps (store) performance these days, which in most cases can help pinpoint a issue with your reach/growth.
I also regret everything about Objective C ;)
[+] [-] mikece|6 years ago|reply
[+] [-] garren|6 years ago|reply
To be clear, I do think Xamarin remains an interesting idea, but it's absolutely not the first thing I'd reach for when starting a x-platform mobile project.
[+] [-] ParanoidShroom|6 years ago|reply