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

71–80 of 342 posts

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

#71

Post by sgc »

chinhodado wrote: post #41
RivieraKid wrote: post #38

Earlier quoted context omitted.

> After all these years, I still find the most difficult and un-natural thing is mixing concurrency / background tasks that must outlive the UI with complex UI component lifecycles. Completely agree. I've been developing for Android since 1.0 and the complex interaction between background tasks and activity lifecycle is the worst part of Android that a significant majority of devs get wrong, introducing subtle bugs.…

I used to think Activity lifecycle management is complex. Then I learned about Fragments and I started to loathe every moment I have to work with them. What a bloated mess: http://staticfree.info/~steve/complete_android_fragment_life...

I started making a semi-complex android app as my first project. Saw the recommendation to use fragments, and I have never looked back because I am way, way too far down the rabbit whole. It's main advantage to me is perhaps nothing. I have no idea and no real way of knowing. But is has tripled my code base, so that is a good thing!

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

#72

Post by yincrash »

RivieraKid wrote: post #38
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…

> After all these years, I still find the most difficult and un-natural thing is mixing concurrency / background tasks that must outlive the UI with complex UI component lifecycles. Completely agree. I've been developing for Android since 1.0 and the complex interaction between background tasks and activity lifecycle is the worst part of Android that a significant majority of devs get wrong, introducing subtle bugs.…

Some historical context, fragments came out with Honeycomb which was the first version of Android specifically for tablets. As such Fragments were meant to be a way write UI in something both tablet and phone layouts could use. So, that's the mysterious reason for the extra layer of complexity. I think at this point, many people don't even use them unless they specifically need to for tablet/phone/tv shared layouts. There are also other alternative patterns that have emerged that are less complicated

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

#73

Post by naiyt »

copperx wrote: post #53
seibelj wrote: post #9

Unless you are writing a Tier 1 application that needs every fancy do-hicky, I don't see the point of 100% native anymore. Use React Native, then if necessary have a devoted native developer for each platform to handle parts that absolutely have to be executed in native and provide a JavaScript API. If you are a big company with tons of money, sure, create duplicate teams to make the same app for each platform. But i…

I'm all for write-once-deploy-everywhere, but React Native is better suited for apps that could be easily written web-only. Maybe I don't get what's better about React Native over a native app that is just a web view.

> Maybe I don't get what's better about React Native over a native app that is just a web view.

It's better because React Native is actually rendering native components. Stuff like PhoneGap never feels or works quite right as a side effect of being rendered in a web view.

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

#74

Post by 0xFFC »

RivieraKid wrote: post #38
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…

> After all these years, I still find the most difficult and un-natural thing is mixing concurrency / background tasks that must outlive the UI with complex UI component lifecycles. Completely agree. I've been developing for Android since 1.0 and the complex interaction between background tasks and activity lifecycle is the worst part of Android that a significant majority of devs get wrong, introducing subtle bugs.…

>Overall, I wouldn't say Android is poorly designed, it's just mediocre

I think it is mostly have to do with company's talent pool and focus.

As far as I can see (I may be wrong, this is my estimate) Google tries hard to devote best talents to 1) ads and Search and it's maintaining 2) Chrome team 3) Google apps and services online and on iPhones.

After these option they try to develop Android as kinda (I don't know what is they correct word, so I am going with kinda) side project because they know the world needs an open platform for competing with apples devices.

The reason because why Android is unacceptable from Google is we all used Google's best products. Chrome and search and we kinda (by default) think about Google as non fallible.

But that's nowhere near the reality, they have limited number of super smart guys, and they try their best to keep core products (search and browser) much better than competitors.

Most of the time when Google does release a new app their iOS apps is better than Android's ones.

We would be okay if Android was from mediocre company. But it is not, it is from Google , which is the best in some areas. But they don't have unlimited talent. They are trying their best to balance.

I am not saying people who worked on Android are not that bright. No I am talking about more broader picture. Of course there some excellent people who work on Android. But I am not talking about 1,2 or three. I am talking about management perspective in broader sense.

This is my personal understanding, I may be completely wrong.

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

#75

Post by lacker »

naiyt wrote: post #70
thirdreplicator wrote: post #65

Given all the grief expressed in the post and the comments, it seems like if someone architected a really nice, developer-friendly native mobile API for any platform you would get droves of devs flocking to it.... Despite the two major players, the market seems wide open as long as they focused on the development experience like what Matz did for Ruby... Programmers are customers too! :)

React Native is getting there. It's still early software with a lot of problems but it has a lot of promise. My anecdotal experience as someone learning mobile development was that React Native was a lot easier to pick up and learn than native Android development. Despite a large number of issues the developer experience has been really slick and I've been able to iterate much faster. Give it a couple of years and I…

it has a lot of promise

Glad to hear it ;-) I'm curious, what have been the main issues for you?

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

#76

Post by clay_to_n »

copperx wrote: post #53
seibelj wrote: post #9

Unless you are writing a Tier 1 application that needs every fancy do-hicky, I don't see the point of 100% native anymore. Use React Native, then if necessary have a devoted native developer for each platform to handle parts that absolutely have to be executed in native and provide a JavaScript API. If you are a big company with tons of money, sure, create duplicate teams to make the same app for each platform. But i…

I'm all for write-once-deploy-everywhere, but React Native is better suited for apps that could be easily written web-only. Maybe I don't get what's better about React Native over a native app that is just a web view.

React Native apps are written in JavaScript, but the components you use are wrappers for actual native view components. So you get native performance (the views can be GPU-accelerated), and native styles.

I've been working with Android for a couple years, and (while I like it) it has it's warts. The architectural patterns required to keep a medium-sized codebase understandable are simply not agreed upon. There are lots of ways to do things, and (as the article points out) even the basic activity + fragment API's are very complex.

I just started playing with React Native, after having some React experience, and it's a breath of fresh air. It feels like cross-platform without obvious negatives, and the rare bonus of being able to wrap + use native components or libraries whenever you need to. You can even share most of your code (even view code for basic views) across IOS and Android. React has a super simple API. The tooling is younger, but is out of the box faster to develop with than Android.

That said, I haven't built a large app in React or React Native, and maybe it bites developers at some scale. No idea how it deals with long-running services, multiple threads, bluetooth or other hardware APIs. But for now, I'm very optimistic.

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

#78

Post by yincrash »

0xFFC wrote: post #74
RivieraKid wrote: post #38

Earlier quoted context omitted.

> After all these years, I still find the most difficult and un-natural thing is mixing concurrency / background tasks that must outlive the UI with complex UI component lifecycles. Completely agree. I've been developing for Android since 1.0 and the complex interaction between background tasks and activity lifecycle is the worst part of Android that a significant majority of devs get wrong, introducing subtle bugs.…

>Overall, I wouldn't say Android is poorly designed, it's just mediocre I think it is mostly have to do with company's talent pool and focus. As far as I can see (I may be wrong, this is my estimate) Google tries hard to devote best talents to 1) ads and Search and it's maintaining 2) Chrome team 3) Google apps and services online and on iPhones. After these option they try to develop Android as kinda (I don't know w…

What are examples of the iOS app of a Google product being better than the Android one? Also, can I ask which OS you primarily use for mobile?

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

#79

Post by pitaj »

lacker wrote: post #75
naiyt wrote: post #70

Earlier quoted context omitted.

React Native is getting there. It's still early software with a lot of problems but it has a lot of promise. My anecdotal experience as someone learning mobile development was that React Native was a lot easier to pick up and learn than native Android development. Despite a large number of issues the developer experience has been really slick and I've been able to iterate much faster. Give it a couple of years and I…

it has a lot of promise Glad to hear it ;-) I'm curious, what have been the main issues for you?

Probably the fact that it's still in active development, so there are breaking changes.

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

#80

Post by MaulingMonkey »

stuaxo wrote: post #56
rifung wrote: post #49

Earlier quoted context omitted.

> The only thing worse than gradle is ANT, which it replaced. What's wrong with ant? I liked it.. It was simple to understand for the most part. It also made it easy to develop without an IDE, although I'll admit I don't know how easy it is now as I stopped doing Android a year ago

Almost every ant file I've had the pleasure of working with in the wild is made badly (having to run things in specific order instead of depending on each other is a classic). With Android, they seemed to change the build files every minor release (my info may be out of date here).

> Almost every ant file I've had the pleasure of working with in the wild is made badly (having to run things in specific order instead of depending on each other is a classic).

Dependencies were a mess. Depend on A and B with both depend on C? C gets pulled in twice, build fails. Workaround? Hack up A to depend on B instead, and have your project depend on A.

Surely adding a new dependency isn't supposed to involve mucking with the build files for half of your existing previously fine third party libs just to get the bloody thing building again - such that all dependencies are only referenced once, yet such that every library has it's dependencies indirectly satisfied by whatever it's been configured to depend on.

I assume I was doing something wrong. I probably sunk a good week into consuming docs and trying stuff out to figure out exactly what. I still have no clue. My coworkers couldn't figure it out either.

I wrote wrapper scripts - and later a full blown partial adb wrapper - to fix the silent deploy failures, after one too many hours of wasted debugging sessions (caused by debugging stale builds) made me crack. A few commands to check file sizes and timestamps... a few regular expressions to parse the results... a few debugging sessions when e.g. the installation defaults for "adb logcat" log output format changed between SDK versions...

After reaching a similar snapping point for ANT, I took the slightly less drastic option of switching to gradle for the next Android project I tackled. I remember gradle being merely 50% as terrible as ANT. I seem to have successfully repressed many of my more detailed memories of dealing with both. Huzzah!

Post reply on HN