neat
It’s Been Real, Android: Why I’m Retiring from Android
321–330 of 342 posts
Re: It’s Been Real, Android: Why I’m Retiring from Android
#322neat
Re: It’s Been Real, Android: Why I’m Retiring from Android
#323neat
Re: It’s Been Real, Android: Why I’m Retiring from Android
#324Earlier quoted context omitted.
> So yes, you do need to understand the new functional reactive approach. You need to know how to write a Gradle build. You have to understand the complexities of proguard rules. It's all pretty frustrating. But I also feel that many of the skills are more easily transferrable - I can also write a Gradle build for a library or I can use IntelliJ to better debug a servlet. With Swift and iOS, there's only vendor you c…
Any resources you'd recommend in particular to learn FRP and how it applies to Android, specifically. As a frequently frustrated intermediate developer I'd greatly appreciate it. I've just begun using RxJava and Robospice to tame my server endpoint call logic, but I know it's just the tip of the iceberg.
It's taken a few false starts and experiments for me to become comfortable. Eric Meijer is an excellent resource for understanding the theoretical underpinnings and the 'why' of it all.
Soundcloud has a reasonable and practical approach on Android: https://www.youtube.com/watch?v=R16OHcZJTno
A good bet is to search Github for projects where common Android APIs or libraries are Rx-ified. You'd be surprised at the economy and simplicity of code you can find in some of the best Rx implementations.
Re: It’s Been Real, Android: Why I’m Retiring from Android
#325Just 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…
Agree.
I was expecting the author to lament on something like java vs swift.
Even that would not be the best argument ever since you can write your android apps entirely in kotlin and it is vastly similar to swift.
A real downside of kotlin is that it complexifies your build (but only the first time you have to setup a complex project with kotlin, dagger, databinding, etc) and that the tooling is not on par with the base java one.
Multidex ? it is far from perfect but it is not a day to day issue. I work on a 200k methods app and multidex actually makes it almost entirely painless.
Gradle ? Nobody can seriously say that builds have gotten worse with gradle. Before it, we had no way to hook up libraries with resources (aar). Now we just have to 'import libname:version' The complaint on the build times is very fair though. The solution is easy though .. just use an high end computer
I use a mid 2015 mbp, it can handle an huge android app without any issue (except that build times are only acceptable, not great).
It really looks like he has been submerged with having 2 platforms to learn at once and has not been able to tackle the basics.
Re: It’s Been Real, Android: Why I’m Retiring from Android
#326Just 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…
Is there a tutorial or book that you can recommend for a newbie to get started with Kotlin,MVP, etc?
There is a great google repo with many architecture samples, including some MVP ones :
https://github.com/googlesamples/android-architecture
For kotlin, no book needed. Go to the language website, read the introduction, maybe a couple of pages on the language features and then complete the kotlin koans. It will give you an overview of most of the language features.
After that, find an android project written in kotlin. Here is one : https://github.com/LostInContext/LostContext-App (there are many others) . Configuring an android project in kotlin the first time can be painful, especially if you have some code generation (dagger, databinding, ...) , so it is way easier to have a working sample to work with.
Re: It’s Been Real, Android: Why I’m Retiring from Android
#327Earlier quoted context omitted.
Personally, I would rather builds be slow than have my build mysteriously break when I'm in that 1%.
For me it depends. If I'm in a development session with lots of iterations where build speed is the bottleneck, I'd take my chances (I do anyway, have to resort to manually compiling individual files). For production/CI/other builds it's a different story, although those usually get built clean so it's not even a consideration.
if you are on a dev session with a lot of iterations, you really want to go the InstantRun (or JRebel) route.
Re: It’s Been Real, Android: Why I’m Retiring from Android
#328I think there are no developers that are true experts in both Android and iOS platforms. Every developer I know either leans towards one platform or another. There are also developers who know both platforms pretty well, but I won't call them experts in either. I consider myself an expert in Android development. The only point that I agree with is multidex, but there are historical reasons for the limitation and I th…
I develop for Android professionally and I am quite good at it (now senior dev in a team of 15 android devs).
I am growing curious about iOS though. I am currently writing an Android app in my spare time with a friend and our next objective is to learn swift in order to make its iOS counterpart.
I have also been offered a couple of iOS jobs (from companies wishing to hire me but not currently hiring for Android).
Finally out of our 15 android devs, 2 of them are also iOS devs (and work for us on both platforms). They quite proficient with both platforms (well, Android anyway but I heard no complaints from the iOS team). Sure, they are not as proficient as our best Android engineers, but they are still pulling their weight.
Maybe the difference is that we are not an agency but a mobile team working on a single app. We can take the time to learn the platform and teach to our colleagues. Maybe that a freelancer does not have this luxury or the adequate structure.
Re: It’s Been Real, Android: Why I’m Retiring from Android
#329Mobile 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…
Qt
Re: It’s Been Real, Android: Why I’m Retiring from Android
#330Earlier quoted context omitted.
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).
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.