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

331–340 of 342 posts

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

#331

Post by BoorishBears »

V-2 wrote: post #330
BoorishBears wrote: post #317

Earlier quoted context omitted.

Support fragments "fixed" nested fragments a little while back, or so they claimed in a change log.

I don't even know; I imagine at that point there wasn't many developers left around still willing to go down that route. As an Android dev I'm in the camp that steers clear of Fragments out of principle, if only possible.

I'm pragmatic about them and they work out. It takes some discipline, but in exchange you get to use a standard back stack manager with more mindshare than any 3rd party replacement like Flow will have. My personal guidelines are:

Only use them in a single form. FragmentTransaction add/remove/replace, no fragment tags in xml to cause inconsistent behavior

Represent state with single AutoValue + Auto Parcel object and save it with Icepick so they work with process death automatically

Implement all interactions with other threads via RxJava so I can unsubscribe and avoid "after onInstanceState exceptions"

Use custom view groups instead of nested fragments since nested fragments tend to not be using the backstack anyways

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

#332

Post by BoorishBears »

V-2 wrote: post #330
BoorishBears wrote: post #317

Earlier quoted context omitted.

Support fragments "fixed" nested fragments a little while back, or so they claimed in a change log.

I don't even know; I imagine at that point there wasn't many developers left around still willing to go down that route. As an Android dev I'm in the camp that steers clear of Fragments out of principle, if only possible.

I'm pragmatic about them and they work out. It takes some discipline, but in exchange you get to use a standard back stack manager with more mindshare than any 3rd party replacement like Flow will have. My personal guidelines are:

Only use them in a single form. FragmentTransaction add/remove/replace, no fragment tags in xml to cause inconsistent behavior

Represent state with single AutoValue + Auto Parcel object and save it with Icepick so they work with process death automatically

Implement all interactions with other threads via RxJava so I can unsubscribe and avoid "after onInstanceState exceptions"

Use custom view groups instead of nested fragments since nested fragments tend to not be using the backstack anyways

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

#333

Post by V-2 »

BoorishBears wrote: post #331
V-2 wrote: post #330

Earlier quoted context omitted.

I don't even know; I imagine at that point there wasn't many developers left around still willing to go down that route. As an Android dev I'm in the camp that steers clear of Fragments out of principle, if only possible.

I'm pragmatic about them and they work out. It takes some discipline, but in exchange you get to use a standard back stack manager with more mindshare than any 3rd party replacement like Flow will have. My personal guidelines are: Only use them in a single form. FragmentTransaction add/remove/replace, no fragment tags in xml to cause inconsistent behavior Represent state with single AutoValue + Auto Parcel object and…

Makes sense, that's a solid approach. No nesting or any other nonsense. But clearly it takes quite some bootstrapping in order to make this functionality solid (as it should be out of the box)...

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

#334

Post by botverse »

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…

> 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.

I don't know where you would insert WebApps in this list but it looks like that they are taking bigger portions of the Google Keynotes lately. Seems that Google is pursuing to arrive quick to the point where WebApps can substitute native apps. You can skip app stores (manifest), run apps in the background, synchronize and receive push notifications (service workers). They have dedicated talented people to design the specs (like Jake Archivald) and they are early adopters of them (Chrome and Android).

WebApps are probably the greater threat to native apps. Apple resists hard to them (imagine the profit loss if anyone can bypass the App Store and it's commission e.g. Amazon).

Webapps can't be used for high performance applications like games, music or VR. But definitely can make that talent or atention to be taken from the native ones.

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

#335

Post by tabulatouch »

pier25 wrote: post #272
tabulatouch wrote: post #156

I've never been an Android developer, but i am happy Xamarin (Forms) developer. It is not without some hassle, need to deal with a little amount of platform-specific code, but it's the way mobile development should be in 2017. Code the experience and functionality, do not loose (too much) time on platforms.

Last time I checked Xamarin Forms about a year ago it was still limited. Is it better now? What are some of its limitations?

They recently added a way to use native components _directly in XAML_ inheriting all the binding goodness. I agree that it is still difficult to have a 100% platform-specific look&feel, but it's an incredible time saver for the majority of apps which deal with _functionality_ and good Ux.

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

#336

Post by BoorishBears »

V-2 wrote: post #333
BoorishBears wrote: post #331

Earlier quoted context omitted.

I'm pragmatic about them and they work out. It takes some discipline, but in exchange you get to use a standard back stack manager with more mindshare than any 3rd party replacement like Flow will have. My personal guidelines are: Only use them in a single form. FragmentTransaction add/remove/replace, no fragment tags in xml to cause inconsistent behavior Represent state with single AutoValue + Auto Parcel object and…

Makes sense, that's a solid approach. No nesting or any other nonsense. But clearly it takes quite some bootstrapping in order to make this functionality solid (as it should be out of the box)...

Fragments follow the general story of Android Framework: tried to be too flexible, introduced unneeded complexity for everyone, suddenly flexibility is of questionable usefulness

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

#337

Post by mncolinlee »

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."

This and the weaknesses of AsyncTask are the reason why RxJava has been adopted so quickly on the Android side. Event buses are dead or dying.

With that said, Rx is still a moving target and it seems to attract a proliferation of redundant, but slightly different, operators that scare away newbies. Observables, schedulers, and map/flatMap/filter are immensely useful to any old school Android developer.

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

#338

Post by kllrnohj »

pjmlp wrote: post #88
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 would expect more from Google. I completely agree and although I only do it as a hobby, there are lots of points that many in the community feel as pain. - They never managed to write a proper working emulator, while other companies had no problem doing so; - The whole debacle of C++ support, had JetBrains not decided to create CLion, to this…

> Choosing to AOT on device instead of doing at the store like everyone else

There's a few major problems with doing it at the store.

1: Google can only AOT for their devices as the AOT depends upon the specific platform version that the app will be installed on (as symbols & offsets change, of course). It's a substantial scalability problem.

2: The compiled version is substantially larger than the dex code. That's a non-trivial cost (in terms of $$$) to put on people in the majority of the world that doesn't have high caps and/or unlimited bandwidth.

3: Apps are signed by the developer, so the store can't recompile the app without breaking the certificate chain. And then the app won't be able to update anymore, and the trust flow back to the original developer is lost.

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

#339

Post by kllrnohj »

rmsaksida wrote: post #226
ntlve wrote: post #186

Earlier quoted context omitted.

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, r…

> As far as I know, there's no simple way to pass an object from the service to the UI.

They are in the same process, you can communicate between them through all the normal Java mechanisms. For example, your UI can just register & unregister a callback on the service directly in its start/stop methods (or in onVisibilityChanged if you'd rather do this in a View instead)

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

#340

Post by lacker »

pier25 wrote: post #270
pitaj wrote: post #79

Earlier quoted context omitted.

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

Also the terrible docs

I'm interested in improving these docs. Can you point to one area that you think is particularly terrible?
Post reply on HN