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

271–280 of 342 posts

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

#271

Post by krschultz »

iainmerrick wrote: post #255
mahyarm wrote: post #21

We adopted buck at work for android & objective-c ios and it's been amazing speed & low-bullshit wise: https://buckbuild.com/setup/getting_started.html If gradle is killing you, I would suggest trying it out. Warning: we have a few guys in a mobile developer experience team, so I don't know how good it is for indies.

I have the opposite experience -- I tried Buck because I really wanted a Blaze/Bazel clone (it wasn't open source at the time). It works but I find it very slow. My project involves lots of native code and genrules, though. If you're mostly building Java code I imagine Buck might work well. If starting from scratch I would try Bazel first.

Buck's speed improvement is heavily dependent on breaking your code into modules. What was your project setup like?

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

#272

Post by pier25 »

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?

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

#273

Post by V-2 »

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

And then there are nested fragments and all the caveats associated with them, but it's all good, it just requires some simple fixes everyone could come up off the top of their head, like http://stackoverflow.com/a/23276145/168719 (the top voted answer)

It's good, because it doesn't require you to use the workaround of deluding the user with a SCREENSHOT of your layout (sic; see the accepted answer above).

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

#275

Post by pier25 »

dmix wrote: post #267
pier25 wrote: post #263

Mobile development in general is a pita. We really need a native cross platform solution that doesn't involve either running a JavaScript VM (ReactNative, NativeScript), writing UI code for each OS (Xamarin), and doesn't rely on a WebView. Xamarin Forms could fit the bill, but last time I checked it wasn't there yet. What other option are there?

Has there ever been a cross platform solution in history that was superior to the native development platform unique to the OS? This seems to be the pipe dream that everyone repeatedly hopes for then gets burned. I'd actually prefer if Apple and Google had their own development platforms so there are competitive driving forces to improve the platform. It will also accelerate experimentation with new tech where one pl…

Superior? Depends on what you are doing.

Working with game engines is a joy since you write "client" code, so to speak, and the engine is compiled for each platform.

QT is also really good, but also really expensive, and you lose native UI which can be a good thing or not depending on your use case.

NativeScript is working on becoming a universal cross platform solution similar to ReactNative. It's already on mobile, and I've read there is a macOS version being worked on.

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

#276

Post by rpeden »

copperx wrote: post #55
cageface wrote: post #13

iOS has plenty of developer pain points as well, although in their case a lot of them are as much a result of dumb Apple policies as they are technical mistakes. I'm going the other way. After six years of iOS work I've had enough. I still think the web is the smart long term bet so that's where I intend to focus my energies.

I agree. However, I would have never thought that developers would be so miserable in 2016. Say what you will about the desktop; developing for it was a pleasure (except for you, Win32 API) compared to what we have in 2016.

The sad part is that things were looking pretty hopeful in 2008-2010.

I particularly liked Cappuccino. It's basically a port of Cocoa to the web. You could design your interface in OSX's Interface Builder. The project is still around and is still being worked on. Sproutcore was pretty similar, and is also still around. Neither of them are being developed as heavily as React or Angular 2, but they have both been mature for a long time, and perhaps don't need a lot of work to be done on them.

Maybe it's just me, but I still find 280Atlas[1] and 280Slides[2] more impressive that many web apps that ship today, and they're nearly 10 years old and ran in browsers far slower and less capable than what we have now.

I actually think more developers would frameworks like these if they didn't feel they had to stay on the latest and greatst JS treadmill to remain employable. And I write that as someone who likes React and Angular. They're both sane ways to develop complex apps, but they don't feel that much better than what was possible 8 years ago.

[1] https://www.youtube.com/watch?v=ouzAPLaFO7I [2] https://www.youtube.com/watch?v=tMZwfh-_QEQ

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

#277

Post by rpeden »

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?

It's still limited in that it's not a good choice if your app requires UI functionality that is very platform specific. I think that's intentional - it isn't intended to be the right solution for every application.

It's still a good choice if your app mainly involves displaying lists and tables of text and images, and data entry forms. The cross platform Map control works quite well too.

I don't remember exactly what is different now from a year ago, but if you list a few of the limitations you faced, I can tell you if they still exist. A quick look at the Pages, Layouts, and Controls section of the Xamarin Forms page might tell you if they've added things that were missing last time you tried it: https://www.xamarin.com/forms

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

#278

Post by kitsunesoba »

Kudos wrote: post #232
pjmlp wrote: post #162

Earlier quoted context omitted.

> Just like the web platform, Android is hugely improved when you leverage the community libraries and tools they provided. Which speaks a lot about the quality of work provided by the platform owner, when the community needs to step up.

No it doesn't it's the same on iOS. Apple didn't come up with dependency/package managers like Carthage or Cocoapods, the community did. There's just enormous amounts of OSS libraries provided by the community too, with ones like Alamofire smoothing out the rough edges of iOS's networking APIs.

The difference to me is that under iOS, you can go without these things (third party libs, Cocoapods/Carthage) and still be OK — you'll be at a relatively minor inconvenience, not ripping your hair out. Particularly with your example of Alamofire/AFNetworking, there's not a ton of functionality you're missing out on if you instead use NSURLSession, since they're both just light wrappers around it. This wasn't always true, but Apple recognized the gap in functionality and fixed it.

I have multiple personal Obj-C/Swift projects on iOS and macOS that don't use any kind of dependency management and use very few third party libraries and working on them has never been an issue or source of pain.

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

#279

Post by pier25 »

rpeden wrote: post #277
pier25 wrote: post #272

Earlier quoted context omitted.

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

It's still limited in that it's not a good choice if your app requires UI functionality that is very platform specific. I think that's intentional - it isn't intended to be the right solution for every application. It's still a good choice if your app mainly involves displaying lists and tables of text and images, and data entry forms. The cross platform Map control works quite well too. I don't remember exactly what…

Thanks for the info. From what I've seen things haven't changed much. The idea still seems to be that Forms is for simple apps that use a number of common components.

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

#280

Post by hinkley »

orangecat wrote: post #246
izacus wrote: post #187

Earlier quoted context omitted.

I'm not sure about the meaningful distinction here. Programming on any platform will be greatly improved by using good (preferrably opensource) libraries. What difference does it make who made them and why? It's such a strange nitpick.

If you're using N separate libraries, that's N times the likelihood of breaking changes that force you to migrate at inconvenient times, and O(N^2) opportunities for bugs caused by incompatibilities.

Two libraries can misbehave because they share a common dependency.

If you assume a roughly logarithmic intersection of shared dependencies that's O(N^2 log n) chances for a bug. But in some communities I'm sure even that is optimistic.

Post reply on HN