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

It’s Been Real, Android: Why I’m Retiring from Android

raptureinvenice.com

Post reply on HN
Print view View original

221–230 of 342 posts

Re: It’s Been Real, Android: Why I’m Retiring from Android

#221

Post by rmsaksida »

vans wrote: post #217

The comparaison with JS is perfect. Like JS is the asm of the web ecosystem (no one wants to write its code just in JS, we generate it instead), default android and IOS way of programming have to be be generated. Try Xamarin [0] or the newcomer flutter [1]. It's such a pain in the ass to dev in raw android or raw ios, use multi platform sdks. And if you start with xamarin, you can target windows phone too, even if no…

I've had some terrible experiences with Xamarin. The tooling is very rudimentary compared to Android Studio, performance is subpar, app size is huge, and development is so slow it's maddening. I wouldn't recommend it other than for some very specific use cases. I'd much rather deal with just plain old Android issues than wrapped-by-Xamarin Android issues and Xamarin-specific issues.

Re: It’s Been Real, Android: Why I’m Retiring from Android

#222

Post by digi_owl »

yojex wrote: post #215
digi_owl wrote: post #146

Earlier quoted context omitted.

Ever since i picked up a Nokia N800 back in the day, my go to setup has been a featurephone with bluetooth and a "smart device". Thus if i need a net connection right damn now, i can pair the smart device with the featurephone and get online.

Can you elaborate on how you do this? I wasn't aware that you could use a feature phone over bluetooth as a wifi hotspot. Are you doing something different?

Well it is not as fast as a wifi connection would be, but it gets the job done. That said, i do not require 24/7 social media and other such coverage.

Basically pair featurephone with smartphone or tablet, and then tell the smartphone or tablet to use the featurephone as their internet connection.

Mind you this is all on Android, and i am not American so i do not have to deal with carriers mucking up my featurephone firmware.

Edit: Just reminded myself that the term used is tethering. If i can't find a wifi hotspot to use, i tether smart device to the featurephone over bluetooth and thus use the phones mobile connection as the net connection for the smart device.

Re: It’s Been Real, Android: Why I’m Retiring from Android

#223

Post by Klathmon »

pjmlp wrote: post #218
Klathmon wrote: post #213

Earlier quoted context omitted.

A self inflicted restriction doesn't make a language bad.

It is not self inflicted, rather imposed by customers. Also the Android operating system isn't a language.

Regardless, it doesn't reflect on the language/os/ecosystem/platform/system/library/runtime

If a company wants to vet all of their software, good on them! But that doesn't mean that anything that's not vetted by them is somehow worse for the majority of users, just that they haven't vetted it yet. So any arguments about how "library x" isn't usable by them won't apply to the vast majority of people, because most don't have that issue, or have no problems vetting that library as well.

Somewhat off topic. Is there a word that encompses the langauge, platform, runtime, etc...? I hate the word "ecosystem", but it seems like the best bet. And using any one of the others brings out comments of "well it's not a language" or "it's not a framework it's a library" or something else.

Re: It’s Been Real, Android: Why I’m Retiring from Android

#224

Post by foobarian »

signal11 wrote: post #205
izacus wrote: post #141

Just like the web platform, Android is hugely improved when you leverage the community libraries and tools they provided. Gradle actually helps a lot with that, since its clear dependency management makes use of external libraries a breeze. If in 2016 you're still complaining about AsyncTasks and its management, you certanly have missed a lot of progress in the last few years. It's not unlike having people complain a…

> Gradle badly needs performance improvement gradle --daemon is a hack, I guess, but I always use it for my builds (even aliased gradle to gradle --daemon). It's far too slow otherwise. On newer gradle releases I believe the daemon is enabled by default.

My problem with gradle is the built in Java dependency resolution is way too aggressive. If you change a class with a static constant it recompiles everything. Even if you don't, it will compile the whole dependency graph to handle some theoretical edge case when it would be enough to compile just the modified file 99% of the time. Oh well.

Re: It’s Been Real, Android: Why I’m Retiring from Android

#225

Post by retox »

gsmiro wrote: post #210
exDM69 wrote: post #202

Earlier quoted context omitted.

> It's not unlike having people complain about JavaScript issues without ever looking at jQuery, React or newer tooling. But this is exactly what makes being a Javascript developer a miserable experience. And I can give Javascript some benefit of the doubt since it's a multi-vendor language with complex standardization processes and all the stakeholders have their own interests and limited financial backing. By contr…

> It's just a mess. I'd expect a relatively painless experience: install dev tools, start a new project, build and go! But no, it's jumping through hoops, requires understanding a myriad of different SDK/platform versions and a constant churn in keeping your apps up to date with new versions while trying not to break backwards compatibility. > And a big part of this mess comes from the fact that device manufacturers…

C# is as easy to get started with as I've seen for any language. I don't see the comparison?

Re: It’s Been Real, Android: Why I’m Retiring from Android

#226

Post by rmsaksida »

ntlve wrote: post #186
clumsysmurf wrote: post #18

A while back, Dianne Hackborn famously said: "We often see questions from developers that are asking from the Android platform engineers about the kinds of design patterns and architectures they use in their apps. But the answer, maybe surprisingly, is we often don't have a strong opinion or really an opinion at all." (1) While that may have been a lofty ideal, in practice Android has many strict requirements on how…

I've found that the best way to deal with this complexity is to ensure that any concurrent work is done in a fire-and-forget kind of style. Concurrent work is submitted to a IntentService (possible backed by a thread pool instead of a single worker thread to speed things up) and if it needs to talk back to the UI it does so via a local sql-db or similar construct. That way the UI can die and get restarted indepedentl…

This looks like absolutely the best approach, but there's one thing I don't like about it: communication between IntentServices and the UI thread feels so... wasteful. The sanest way to do it, I think, is keep communication to a minimum, relying solely on the local DB as a source of information. But then every operation you do to fetch remote data immediately results in at least a couple of DB operations (store it, read it) and a ton of serialization. As far as I know, there's no simple way to pass an object from the service to the UI.

Re: It’s Been Real, Android: Why I’m Retiring from Android

#227

Post by teek »

> Google’s adoption of gradle has been a disaster and proved to be a terrible decision. It did help out with some previous issues, namely multiple app targets, but it’s slowed down compilation severely. It also makes for masochistic configuration files with major redundancy and fragmented dependency hosts. Getting an app to compile shouldn’t be a challenge.

To be fair iOS dependency management is also a huge pain. CocoaPods is worse than working with Gradle in my opinion.

Re: It’s Been Real, Android: Why I’m Retiring from Android

#228

Post by generalpf »

ClayFerguson wrote: post #17

Developers do need to pick a set of core technologies, and stick to it or a career can fall apart I bet. I don't know from experience. I've been a Java DEV ever since MSFT tried to hijack the Java language with a proprietary version back in 1998, and I abandoned MSFT and never went back. I can imagine trying to be both iOS and Android developer would be about as insane as trying to be both .NET and Java developer. Oi…

Coincidentally I am certified in .NET development (MCSD.NET) and Java development (SCJP and SCWCD), and now I do iOS and Android development. It's possible!

Re: It’s Been Real, Android: Why I’m Retiring from Android

#229

Post by izacus »

exDM69 wrote: post #202
izacus wrote: post #141

Just like the web platform, Android is hugely improved when you leverage the community libraries and tools they provided. Gradle actually helps a lot with that, since its clear dependency management makes use of external libraries a breeze. If in 2016 you're still complaining about AsyncTasks and its management, you certanly have missed a lot of progress in the last few years. It's not unlike having people complain a…

> It's not unlike having people complain about JavaScript issues without ever looking at jQuery, React or newer tooling. But this is exactly what makes being a Javascript developer a miserable experience. And I can give Javascript some benefit of the doubt since it's a multi-vendor language with complex standardization processes and all the stakeholders have their own interests and limited financial backing. By contr…

You can open Android Studio, create a new project and "Go!". It'll work. Then you can add a single line of code to dependencies and you get even better APIs!

I also have no idea why are you mixing the device updates into the developer tooling argument. New apps are (should be - and the tutorials tell you so) developed with API 19+ in mind which means that you'll have to work for quite a while to get any problems with fragmentation and updates. You can even start development on API 21 and ditch support libraries all together and STILL not shed significant amount of userbase.

Re: It’s Been Real, Android: Why I’m Retiring from Android

#230

Post by z3t4 »

newscracker wrote: post #134
z3t4 wrote: post #113

I see two types of dev methods 1) Write it all down, read through the code a few times. Then compile and do a full test. 2) Write in steps, compile and test after each step. The later is a Pita on low level. And produce more bugs.

Regardless of the platform, for any application with a non-trivial amount of complexity, iterative development is the best approach. I don't understand how anyone could "write it all down, read through the code a few times and test" and not produce a buggier application that doesn't meet most expectations. It does help to do some initial design work, create abstractions, loose coupling, etc. Iterative development doe…

I think everyone prefer iterative development. I love web dev because I can get instant gratifications (no compile time). I think it's mostly because I'm lazy though.

I also manage a legacy system where I make hot fixes in production, where setting up a testing environment is not practical. While I do introduce bugs, they are far less because I'm forced to plan carefully, and know how everything works.

One problem with development is that it's hard to predict what will happen, and thus it gets difficult to make estimates. But if you carefully analyze and plan, things will go much smoother.

Post reply on HN